• 原文地址：Standard Package Layout
• 原文作者：Ben Johnson
• 譯文出自：掘金翻譯計劃
• 本文永久鏈接：github.com/xitu/gold-m…
• 譯者：steinliber
• 校對者：Albert

一般來說是使用 Vendoring 作為包管理工具。在 Go 社區已經可以看到一些重要的問題，但是有一個問題在社區中很少被提及，即應用的包布局。

我曾經參與編寫過的每一個 Go 應用對這個問題似乎都有不同的答案， 我該如何組織我的代碼？ 。一些應用會把所有的東西都放到一個包里，而其它應用則會選擇按照類型或模塊來組織代碼。如果沒有一個適用于整個團隊的策略，你將發現代碼會散布在你應用不同包里面。對于 Go 應用程序包布局的設計我們需要一個更好的標準。

我提議有一個更好的方式。通過遵循一些簡單的規則我們就可以解耦我們的代碼，使之更易于測試并且可以使我們的項目有一致的結構，在深入探討這個方式之前，讓我們來看下目前人們組織項目一些最常見的方式。

---

更新：我收到了很多關于這種方式非常棒的反饋，其中最多的是想要看到一個使用這種方式構建的應用。于是我已經開始重新寫一系列文章記錄使用這種包布局方式來構建應用，叫做 Building WTF Dial.

常見的有缺陷的方式

現在似乎有幾種通用的 Go 應用組織方式，它們都有各自的缺陷。

方法 #1： 單個包

把你所有的代碼都扔進一個包，對于一個小的應用來說這樣就可以很好的工作。它消除了產生循環依賴問題的可能，因為在你的應用代碼中并沒有任何依賴。

我曾經看到過使用這種方式構建超過 10K 行代碼的應用 SLOC。但是一旦代碼量超過這個數量，定位和獨立你的代碼將會變得非常困難。

方法 #2: Rails 風格布局

另一種組織你代碼的方式是根據它的功能類型。比如說，把所有你的 處理器，控制器，模型代碼都分別放在獨立的包中。我之前看到很多前 Rails 開發者(包括我自己)都使用這種方式來組織代碼。

但是使用這種方式有兩個問題。首先你的命名將會變得糟糕透頂，你最終會得到類似 controller.UserController 這樣的命名，在這種命名中你重復了包名和類型名。對于命名，我是一個有執念的人。我相信當你在去除無用代碼時名稱是你最好的文檔。好的名稱也是高質量代碼的代表，當其他人讀代碼時總是最先注意到這個。

更大的問題在于循環依賴。你不同的功能類型也許需要互相引用對方。只有當你維護單向依賴關系時，這個應用才能夠工作，但是在很多時候維護單向依賴并不簡單。

方法 #3：根據模塊組織代碼

這個方式類似于前面的 Rails 風格布局，但是我們是使用模塊來組織代碼而不是功能。比如說，你或許會有一個 user 包和一個 account 包。

我們發現使用這種方式也會遇到之前同樣的問題。我們最后也會遇到像 users.User. 這樣可怕的命名。如果我們的 accounts.Controller 需要和 users.Controller 進行交互，那么我們同樣會遇到相同的循環依賴問題，反之亦然。

一個更好的方式

我在項目使用的包組織策略涉及到以下4個簡單的原則：

Root 包是用于域類型的

通過依賴關系來組織子包

使用一個共享的 mock 子包

Main 包將依賴關系聯系到一起

這些規則幫助隔離我們的包并且在整個應用中定義了一個清晰的領域語言。讓我們來看看這些規則在實踐中是如何使用的。

#1. Root 包是用于域類型的

你的應用有一種用于描述數據和進程是如何交互的邏輯層面的高級語言。這就是你的域。如果你有一個電子商務應用，那你的域就會涉及到客戶，賬戶，信用卡支付，以及存貨等內容。如果你的應用是 Facebook，你的域就會是用戶，點贊以及用戶間的關系。這些是不依賴于你基礎技術的東西。

我把我的域類型放在 root 保存。這個包只包含了簡單的數據類型，比如說包含用戶信息的 User 結構或者是獲取和保存用戶數據的 UserService 接口。

這個 root 包會像以下這樣：

package myapptype User struct {ID intName stringAddress Address }type UserService interface {User(id int) (*User, error)Users() ([]*User, error)CreateUser(u *User) errorDeleteUser(id int) error } 復制代碼

這使你的 root 包變的非常簡單。你也可以在這個包里放包含執行操作的類型，但是它們應該只依賴于其它的域類型。比如說，你可以在這個包加一個定期輪詢 UserService 的類型。但是，它不應該調用外部服務或者將數據保存到數據庫。這些是實現細節。

root 包不應該依賴于你應用中的其它任何包

#2. 通過依賴關系來組織子包

如果你的 root 包并不允許有外部依賴，那么我們就必須把這些依賴放到子包里。在這種包布局的方式中，子包就相當于你域和實現之間的適配器。

比如說，你的 UserService 可能是由 PostgreSQL 數據庫提供支持。你可以在應用中引入一個叫做 postgres 的子包用來提供 postgres.UserService 的實現。

package postgresimport ("database/sql""github.com/benbjohnson/myapp"_ "github.com/lib/pq" )// UserService represents a PostgreSQL implementation of myapp.UserService. type UserService struct {DB *sql.DB }// User returns a user for a given id. func (s *UserService) User(id int) (*myapp.User, error) {var u myapp.Userrow := db.QueryRow(`SELECT id, name FROM users WHERE id = $1`, id)if row.Scan(&u.ID, &u.Name); err != nil {return nil, err}return &u, nil }// implement remaining myapp.UserService interface... 復制代碼

這樣就隔離了我們對 PostgreSQL 的依賴關系，從而簡化了測試，并為我們將來遷移到其它數據庫提供了一種簡單的方法。如果你打算支持像 BoltDB 這種數據庫的實現，就可以把它看作是一個可插拔體系結構。

這也為你實現層級提供了一種方式。比如說你想要在 Postgresql 前面加一個內存緩存 LRU cache。你可以添加一個 UserCache 類型來包裝你的 Postgresql 實現。

package myapp// UserCache wraps a UserService to provide an in-memory cache. type UserCache struct {cache map[int]*Userservice UserService }// NewUserCache returns a new read-through cache for service. func NewUserCache(service UserService) *UserCache {return &UserCache{cache: make(map[int]*User),service: service,} }// User returns a user for a given id. // Returns the cached instance if available. func (c *UserCache) User(id int) (*User, error) {// Check the local cache first.if u := c.cache[id]]; u != nil {return u, nil}// Otherwise fetch from the underlying service.u, err := c.service.User(id)if err != nil {return nil, err} else if u != nil {c.cache[id] = u}return u, err } 復制代碼

我們也可以在標準庫中看到使用這種方式組織代碼。io. Reader 是一個用于讀取字節的域類型，它的實現是通過組織依賴關系 tar.Reader，gzip.Reader， multipart.Reader 來實現的。在標準庫中也可以看到層級方式，經?？梢钥吹?os.File 被 bufio.Reader，gzip.Reader， tar.Reader 這樣一個個層級封裝。

依賴之間的依賴

依賴關系并不是孤立的。你可以把 User 數據保存在 Postgresql 中，而把金融交易數據保存在像 Stripe 這樣的第三方服務。在這種情況下我們用一個邏輯上的域類型來封裝對 Stripe 的依賴，讓我們把它叫做 TransactionService 。

通過把我們的 TransactionService 添加到 UserService ，我們解耦了我們的兩個依賴。

type UserService struct {DB *sql.DBTransactionService myapp.TransactionService } 復制代碼

現在我們的依賴只通過共有的領域語言交流。這意味著我們可以把 Postgresql 切換為 MySQL 或者把 Strip 切換為另一個支付的內部處理器而不用擔心影響到其它的依賴。

不要只對第三方的依賴添加這個限制

這聽起來雖然有點奇怪，但是我也使用這種方式來隔離對標準庫的依賴關系。例如 net/http 包只是另一種依賴。我們可以通過在應用中包含一個 http 子包來隔離對它的依賴。

有一個名稱與它所包裝依賴相同的包看起來似乎很奇怪，但是這只是內部實現。除非你允許你應用的其它部分使用 net/http ，否則在你的應用中就不會有命名沖突。復制 http 名稱的好處在于它要求你把所有 HTTP 相關代碼都隔離到 http 包中。

package httpimport ("net/http""github.com/benbjohnson/myapp" )type Handler struct {UserService myapp.UserService }func (h *Handler) ServeHTTP(w http.ResponseWriter, r *http.Request) {// handle request } 復制代碼

現在，你的 http.Handler 就像是一個在域和 HTTP 協議之前的適配器。

#3. 使用一個共享的 mock 子包

因為我們的依賴通過域接口已經和其它的依賴隔離了，所以我們可以使用這些連接點來注入模擬實現。

這里有幾個像 GoMock 的模擬庫來幫你生成模擬數據，但是我個人更喜歡自己寫。我發現許多的模擬工具都過于復雜了。

我使用的模擬非常簡單。比如說，一個對 UserService 的模擬就像下面這樣：

package mockimport "github.com/benbjohnson/myapp"// UserService represents a mock implementation of myapp.UserService. type UserService struct {UserFn func(id int) (*myapp.User, error)UserInvoked boolUsersFn func() ([]*myapp.User, error)UsersInvoked bool// additional function implementations... }// User invokes the mock implementation and marks the function as invoked. func (s *UserService) User(id int) (*myapp.User, error) {s.UserInvoked = truereturn s.UserFn(id) }// additional functions: Users(), CreateUser(), DeleteUser() 復制代碼

這個模擬讓我可以注入函數到任何使用 myapp.UserService 的接口來驗證參數，返回預期的數據或者注入失敗。

假設我們想測試我們上面構建的 http.Handler ：

package http_testimport ("testing""net/http""net/http/httptest""github.com/benbjohnson/myapp/mock" )func TestHandler(t *testing.T) {// Inject our mock into our handler.var us mock.UserServicevar h Handlerh.UserService = &us// Mock our User() call.us.UserFn = func(id int) (*myapp.User, error) {if id != 100 {t.Fatalf("unexpected id: %d", id)}return &myapp.User{ID: 100, Name: "susy"}, nil}// Invoke the handler.w := httptest.NewRecorder()r, _ := http.NewRequest("GET", "/users/100", nil)h.ServeHTTP(w, r)// Validate mock.if !us.UserInvoked {t.Fatal("expected User() to be invoked")} } 復制代碼

我們的模擬完全隔離了我們的單元測試，讓我們只測試 HTTP 協議的處理。

#4. Main 包將依賴關系聯系到一起

當所有這些依賴包獨立維護時，你可能想知道如何把它們聚合到一起。這就是 main 包的工作。

Main 包布局

一個應用可能會產生多個二進制文件， 所以我們使用 Go 的慣例把我們的 main 包作為 cmd 包的子目錄。 比如，我們的項目中可能有一個 myapp 服務二進制文件，還有一個用于在終端管理服務 的 myappctl 客戶端二進制文件。我們的包將像這樣布局：

myapp/cmd/myapp/main.gomyappctl/main.go 復制代碼

在編譯時注入依賴

"依賴注入"這個詞已經成了一個不好的說法，它讓人聯想到 Spring 冗長的XML文件。然而，這個術語所代表的真正含義只是要把依賴關系傳遞給我們的對象，而不是要求對象構建或者找到這個依賴關系本身。

在 main 包中我們可以選擇哪些依賴注入到哪些對象中。因為 main 包只是簡單的連接了各部分，所以 main 中的代碼往往是比較小和瑣碎的。

package mainimport ("log""os""github.com/benbjohnson/myapp""github.com/benbjohnson/myapp/postgres""github.com/benbjohnson/myapp/http" )func main() {// Connect to database.db, err := postgres.Open(os.Getenv("DB"))if err != nil {log.Fatal(err)}defer db.Close()// Create services.us := &postgres.UserService{DB: db}// Attach to HTTP handler.var h http.Handlerh.UserService = us// start http server... } 復制代碼

注意到你的 main 包也是一個適配器很重要。他把所有終端連接到你的域。

結論

應用設計是一個難題。盡管做出了這么多的設計決策，如果沒有一套堅實的原則來指導，那你的問題只會變的更糟。我們已經列舉了 Go 應用布局設計的幾種方式，并且我們也看到了很多它們的缺陷。

我相信從依賴關系的角度來看待設計會使代碼組織的更簡單，更加容易理解。首先我們設計我們的領域語言，然后我們隔離我們的依賴關系，之后介紹了使用 mock 來隔離我們的測試，最后我們把所有東西都在 main 包中綁了起來。

可以在下一個你設計的應用中考慮下這些原則。如果有您有任何問題或者想討論這個設計，請在 Twitter 上 @benbjohnson與我聯系，或者在Gopher slack 查找 benbjohnson 來找到我。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、后端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。

總結

以上是生活随笔為你收集整理的[译] 标准化的包布局（Standard Package Layout）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。