GO——項目結構

我從今年（2022 年）開始真正使用 Golang 進行編程，我立即做的事情就是尋找參考資料，以了解改進專案結構的最佳方式。這篇文章只是討論同一主題的許多其他文章之一，也許這就是我決定寫它的原因。

首先，golang 在處理資料夾/套件的方式上已經非常不同，而且，為了改進，它有一個非常固執己見的本質，許多官方文件告訴我們做某事的「goway」方式是什麼（完整）然而，在你組織文件和文件夾的方式中，並沒有真正的方向，所以每個人都對這部分給出了自己對世界的解釋。

我將把這篇文章分成 3 個參考文獻，然後展示這些參考文獻的混合在專案中的效果。

第一個參考

一個有效的複雜系統總是從一個有效的簡單系統演變而來。
-- 加爾定律

對於小型應用程序，專案結構應該簡單。

https://innovation.enova.com/gophercon-2018-how-do-you-struct-your-go-apps/

第二參考

「社區」對 Go 生態系統中常見的一組歷史和新興設計佈局模式進行了調查。這次調查中有很多很酷的東西，但引起我注意的是 /cmd 和 /internal 資料夾。

/指令

該專案的主要應用。
每個應用程式的目錄名稱必須與您想要的可執行檔的名稱相符（例如 /cmd/myapp）。

/內部的

私人應用程式和函式庫程式碼。您不希望其他人將這些程式碼匯入到他們的應用程式或庫中。請注意，這種佈局模式是由 Go 編譯器本身強加的。

第三參考

能夠更好地將「細節」與實際提供價值分開的架構。

結果

對於一個簡單的應用程序，我嘗試保持簡單，但是，當範圍變大一點時，我嘗試稍微區分什麼是“核心”/域和什麼是細節/基礎設施。

請注意，在 cmd 中，我沒有 tuttipet 資料夾，正如參考項目所建議的那樣。起初我嘗試使用建議的模式，但由於這個 API 已經推出了命令列介面和 terraform 提供程序，我決定保留這種方式。

快速放大核心。我在這裡嘗試簡單化，不創建資料夾。我只與外在世界保持 1 個接觸點（main.go），凡是概括的都有自己的文件，凡是不概括的都保留在其上下文中，簡單。

使用 tuttipet.New（簡短、簡潔且令人回味），「髒」層可以與用例互動（我發現用例這個詞比互動器更容易理解）

快速放大細節。以下是該領域成功的簡單工具。

結論

在Golang 提供的道路上，我仍然是一個容易被說服的人，仍在嘗試弄清楚可以用它做什麼，但是，儘管我不喜歡Go 做某些事情的方式，但事實證明它是非常簡單且強大。

總結，盡可能保持簡單，如果它變得太複雜......我會回到繪圖板。

其他參考資料

https://dev.to/booscaaa/implementando-clean-architecture-com-golang-4n0a
https://github.com/golang-standards/project-layout
https://blog.boot.dev/golang/golang-project-struct/
https://github.com/bnkamalesh/goapp
https://www.wolfe.id.au/2020/03/10/how-do-i-struct-my-go-project/
https://blog.logrocket.com/flat-struct-vs-layered-architecture-structuring-your-go-app/
https://developer20.com/how-to-struct-go-code/
https://dev.to/jinxankit/go-project-struct-and-guidelines-4ccm
https://github.com/bxcodec/go-clean-arch
https://golangexample.com/example-go-clean-architecture-folder-pattern/
https://www.calhoun.io/flat-application-struct/
https://go.dev/doc/ effective_go#names
https://go.dev/blog/package-names

原文：https://medium.com/@espigah/go-layout-do-projeto-18aacce8089d

以上是GO——項目結構的詳細內容。更多資訊請關注PHP中文網其他相關文章！