[译] 标准化的包布局（Standard Package Layout）
- 原文地址：Standard Package Layout
- 原文作者：Ben Johnson
- 譯文出自：掘金翻譯計劃
- 本文永久鏈接：github.com/xitu/gold-m…
- 譯者：steinliber
- 校對者：Albert
一般來說是使用 Vendoring 作為包管理工具。在 Go 社區(qū)已經(jīng)可以看到一些重要的問題，但是有一個問題在社區(qū)中很少被提及，即應(yīng)用的包布局。
我曾經(jīng)參與編寫過的每一個 Go 應(yīng)用對這個問題似乎都有不同的答案， 我該如何組織我的代碼？ 。一些應(yīng)用會把所有的東西都放到一個包里，而其它應(yīng)用則會選擇按照類型或模塊來組織代碼。如果沒有一個適用于整個團隊的策略，你將發(fā)現(xiàn)代碼會散布在你應(yīng)用不同包里面。對于 Go 應(yīng)用程序包布局的設(shè)計我們需要一個更好的標(biāo)準(zhǔn)。
我提議有一個更好的方式。通過遵循一些簡單的規(guī)則我們就可以解耦我們的代碼，使之更易于測試并且可以使我們的項目有一致的結(jié)構(gòu)，在深入探討這個方式之前，讓我們來看下目前人們組織項目一些最常見的方式。
更新：我收到了很多關(guān)于這種方式非常棒的反饋，其中最多的是想要看到一個使用這種方式構(gòu)建的應(yīng)用。于是我已經(jīng)開始重新寫一系列文章記錄使用這種包布局方式來構(gòu)建應(yīng)用，叫做 Building WTF Dial.
常見的有缺陷的方式
現(xiàn)在似乎有幾種通用的 Go 應(yīng)用組織方式，它們都有各自的缺陷。
方法 #1： 單個包
把你所有的代碼都扔進(jìn)一個包，對于一個小的應(yīng)用來說這樣就可以很好的工作。它消除了產(chǎn)生循環(huán)依賴問題的可能，因為在你的應(yīng)用代碼中并沒有任何依賴。
我曾經(jīng)看到過使用這種方式構(gòu)建超過 10K 行代碼的應(yīng)用 SLOC。但是一旦代碼量超過這個數(shù)量，定位和獨立你的代碼將會變得非常困難。
方法 #2: Rails 風(fēng)格布局
另一種組織你代碼的方式是根據(jù)它的功能類型。比如說，把所有你的 處理器，控制器，模型代碼都分別放在獨立的包中。我之前看到很多前 Rails 開發(fā)者(包括我自己)都使用這種方式來組織代碼。
但是使用這種方式有兩個問題。首先你的命名將會變得糟糕透頂，你最終會得到類似 controller.UserController 這樣的命名，在這種命名中你重復(fù)了包名和類型名。對于命名，我是一個有執(zhí)念的人。我相信當(dāng)你在去除無用代碼時名稱是你最好的文檔。好的名稱也是高質(zhì)量代碼的代表，當(dāng)其他人讀代碼時總是最先注意到這個。
更大的問題在于循環(huán)依賴。你不同的功能類型也許需要互相引用對方。只有當(dāng)你維護(hù)單向依賴關(guān)系時，這個應(yīng)用才能夠工作，但是在很多時候維護(hù)單向依賴并不簡單。
方法 #3：根據(jù)模塊組織代碼
這個方式類似于前面的 Rails 風(fēng)格布局，但是我們是使用模塊來組織代碼而不是功能。比如說，你或許會有一個 user 包和一個 account 包。
我們發(fā)現(xiàn)使用這種方式也會遇到之前同樣的問題。我們最后也會遇到像 users.User. 這樣可怕的命名。如果我們的 accounts.Controller 需要和 users.Controller 進(jìn)行交互，那么我們同樣會遇到相同的循環(huán)依賴問題，反之亦然。
一個更好的方式
我在項目使用的包組織策略涉及到以下4個簡單的原則：
這些規(guī)則幫助隔離我們的包并且在整個應(yīng)用中定義了一個清晰的領(lǐng)域語言。讓我們來看看這些規(guī)則在實踐中是如何使用的。
#1. Root 包是用于域類型的
你的應(yīng)用有一種用于描述數(shù)據(jù)和進(jìn)程是如何交互的邏輯層面的高級語言。這就是你的域。如果你有一個電子商務(wù)應(yīng)用，那你的域就會涉及到客戶，賬戶，信用卡支付，以及存貨等內(nèi)容。如果你的應(yīng)用是 Facebook，你的域就會是用戶，點贊以及用戶間的關(guān)系。這些是不依賴于你基礎(chǔ)技術(shù)的東西。
我把我的域類型放在 root 保存。這個包只包含了簡單的數(shù)據(jù)類型，比如說包含用戶信息的 User 結(jié)構(gòu)或者是獲取和保存用戶數(shù)據(jù)的 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 } 復(fù)制代碼這使你的 root 包變的非常簡單。你也可以在這個包里放包含執(zhí)行操作的類型，但是它們應(yīng)該只依賴于其它的域類型。比如說，你可以在這個包加一個定期輪詢 UserService 的類型。但是，它不應(yīng)該調(diào)用外部服務(wù)或者將數(shù)據(jù)保存到數(shù)據(jù)庫。這些是實現(xiàn)細(xì)節(jié)。
root 包不應(yīng)該依賴于你應(yīng)用中的其它任何包
#2. 通過依賴關(guān)系來組織子包
如果你的 root 包并不允許有外部依賴，那么我們就必須把這些依賴放到子包里。在這種包布局的方式中，子包就相當(dāng)于你域和實現(xiàn)之間的適配器。
比如說，你的 UserService 可能是由 PostgreSQL 數(shù)據(jù)庫提供支持。你可以在應(yīng)用中引入一個叫做 postgres 的子包用來提供 postgres.UserService 的實現(xiàn)。
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... 復(fù)制代碼這樣就隔離了我們對 PostgreSQL 的依賴關(guān)系，從而簡化了測試，并為我們將來遷移到其它數(shù)據(jù)庫提供了一種簡單的方法。如果你打算支持像 BoltDB 這種數(shù)據(jù)庫的實現(xiàn)，就可以把它看作是一個可插拔體系結(jié)構(gòu)。
這也為你實現(xiàn)層級提供了一種方式。比如說你想要在 Postgresql 前面加一個內(nèi)存緩存 LRU cache。你可以添加一個 UserCache 類型來包裝你的 Postgresql 實現(xiàn)。
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 } 復(fù)制代碼我們也可以在標(biāo)準(zhǔn)庫中看到使用這種方式組織代碼。io. Reader 是一個用于讀取字節(jié)的域類型，它的實現(xiàn)是通過組織依賴關(guān)系 tar.Reader，gzip.Reader， multipart.Reader 來實現(xiàn)的。在標(biāo)準(zhǔn)庫中也可以看到層級方式，經(jīng)常可以看到 os.File 被 bufio.Reader，gzip.Reader， tar.Reader 這樣一個個層級封裝。
依賴之間的依賴
依賴關(guān)系并不是孤立的。你可以把 User 數(shù)據(jù)保存在 Postgresql 中，而把金融交易數(shù)據(jù)保存在像 Stripe 這樣的第三方服務(wù)。在這種情況下我們用一個邏輯上的域類型來封裝對 Stripe 的依賴，讓我們把它叫做 TransactionService 。
通過把我們的 TransactionService 添加到 UserService ，我們解耦了我們的兩個依賴。
type UserService struct {DB *sql.DBTransactionService myapp.TransactionService } 復(fù)制代碼現(xiàn)在我們的依賴只通過共有的領(lǐng)域語言交流。這意味著我們可以把 Postgresql 切換為 MySQL 或者把 Strip 切換為另一個支付的內(nèi)部處理器而不用擔(dān)心影響到其它的依賴。
不要只對第三方的依賴添加這個限制
這聽起來雖然有點奇怪，但是我也使用這種方式來隔離對標(biāo)準(zhǔn)庫的依賴關(guān)系。例如 net/http 包只是另一種依賴。我們可以通過在應(yīng)用中包含一個 http 子包來隔離對它的依賴。
有一個名稱與它所包裝依賴相同的包看起來似乎很奇怪，但是這只是內(nèi)部實現(xiàn)。除非你允許你應(yīng)用的其它部分使用 net/http ，否則在你的應(yīng)用中就不會有命名沖突。復(fù)制 http 名稱的好處在于它要求你把所有 HTTP 相關(guān)代碼都隔離到 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 } 復(fù)制代碼現(xiàn)在，你的 http.Handler 就像是一個在域和 HTTP 協(xié)議之前的適配器。
#3. 使用一個共享的 mock 子包
因為我們的依賴通過域接口已經(jīng)和其它的依賴隔離了，所以我們可以使用這些連接點來注入模擬實現(xiàn)。
這里有幾個像 GoMock 的模擬庫來幫你生成模擬數(shù)據(jù)，但是我個人更喜歡自己寫。我發(fā)現(xiàn)許多的模擬工具都過于復(fù)雜了。
我使用的模擬非常簡單。比如說，一個對 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() 復(fù)制代碼這個模擬讓我可以注入函數(shù)到任何使用 myapp.UserService 的接口來驗證參數(shù)，返回預(yù)期的數(shù)據(jù)或者注入失敗。
假設(shè)我們想測試我們上面構(gòu)建的 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")} } 復(fù)制代碼我們的模擬完全隔離了我們的單元測試，讓我們只測試 HTTP 協(xié)議的處理。
#4. Main 包將依賴關(guān)系聯(lián)系到一起
當(dāng)所有這些依賴包獨立維護(hù)時，你可能想知道如何把它們聚合到一起。這就是 main 包的工作。
Main 包布局
一個應(yīng)用可能會產(chǎn)生多個二進(jìn)制文件， 所以我們使用 Go 的慣例把我們的 main 包作為 cmd 包的子目錄。 比如，我們的項目中可能有一個 myapp 服務(wù)二進(jìn)制文件，還有一個用于在終端管理服務(wù) 的 myappctl 客戶端二進(jìn)制文件。我們的包將像這樣布局：
myapp/cmd/myapp/main.gomyappctl/main.go 復(fù)制代碼在編譯時注入依賴
"依賴注入"這個詞已經(jīng)成了一個不好的說法，它讓人聯(lián)想到 Spring 冗長的XML文件。然而，這個術(shù)語所代表的真正含義只是要把依賴關(guān)系傳遞給我們的對象，而不是要求對象構(gòu)建或者找到這個依賴關(guān)系本身。
在 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... } 復(fù)制代碼注意到你的 main 包也是一個適配器很重要。他把所有終端連接到你的域。
結(jié)論
應(yīng)用設(shè)計是一個難題。盡管做出了這么多的設(shè)計決策，如果沒有一套堅實的原則來指導(dǎo)，那你的問題只會變的更糟。我們已經(jīng)列舉了 Go 應(yīng)用布局設(shè)計的幾種方式，并且我們也看到了很多它們的缺陷。
我相信從依賴關(guān)系的角度來看待設(shè)計會使代碼組織的更簡單，更加容易理解。首先我們設(shè)計我們的領(lǐng)域語言，然后我們隔離我們的依賴關(guān)系，之后介紹了使用 mock 來隔離我們的測試，最后我們把所有東西都在 main 包中綁了起來。
可以在下一個你設(shè)計的應(yīng)用中考慮下這些原則。如果有您有任何問題或者想討論這個設(shè)計，請在 Twitter 上 @benbjohnson與我聯(lián)系，或者在Gopher slack 查找 benbjohnson 來找到我。
掘金翻譯計劃 是一個翻譯優(yōu)質(zhì)互聯(lián)網(wǎng)技術(shù)文章的社區(qū)，文章來源為 掘金 上的英文分享文章。內(nèi)容覆蓋 Android、iOS、前端、后端、區(qū)塊鏈、產(chǎn)品、設(shè)計、人工智能等領(lǐng)域，想要查看更多優(yōu)質(zhì)譯文請持續(xù)關(guān)注 掘金翻譯計劃、官方微博、知乎專欄。
總結(jié)
以上是生活随笔為你收集整理的[译] 标准化的包布局（Standard Package Layout）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： netstat命令使用范例
- 下一篇： NIO - Selector源码分析