正文

如果你嘗試學習Go，或者你正在為自己建立一個Poc或者一個玩具項目，這個項目布局是沒有啥必要的，從一些簡單的事情開始（一個main文件綽綽有余）。當有更多的人參與這個項目的時候，你講需要更多的結構，包括需要一個tookit來方便生成項目的模板，盡可能大家統一的工程目錄布局

本文章圍繞github.com/golang-stan… 進行說明

/cmd

本項目的主干。 每個應用程序的目錄名應該與你想要的可執行文件的名稱相匹配（例如：/cmd/myapp）

不要在這個項目中放置太多的代碼，如果你認為代碼導入并在其他項目中使用，那么他應該位于/pkg目錄中，如果代碼不是可重用的，或者你不希望其他人重用他，請將該代碼放到/internal目錄中。

/internal

不希望對外進行共享的代碼，internal目錄中也可以放置一些子包結構，已做到更加細化的切分，如：

|--internal
|   |
|   |--demo
|       |--biz
|       |--data
|       |--service

/pkg

外部應用程序可以使用的代碼庫，（例如：/pkg/publiclib)其他項目會導入這些代碼庫，所以放入到該目錄下的代碼要三思~注意：/internal目錄是確保私有包不可導入的私有方法，因為他是由Go在編譯時強制執行的。/pkg 仍然是一種更好的方式，可以顯示的表示目錄中的代碼對于其他人來說是安全使用的好方法。

/pkg目錄內可以參考GO標準庫的組織形式，按照功能分類，/internal/pkg一般用于項目內的，跨多個應用的公共共享代碼，但是其作用域僅在單個工程內。

|--pkg
|  |
|  |--cache
|  |   |--memcache
|  |   |--redis
|  |
|  |--conf
|      |--dsn
|      |--env
|      |--flagvar
|      |--paladin

/docs,/example,/pkg,/third_parth,/tools

這些跟上文說的/pkg和/internal都同屬根目錄下的目錄結構

• /docs 放置一些項目說明文檔
• /example 放置一些項目的使用示例
• /thrid_parth 三方的一些依賴文件，如：idl文件
• /tools 放置一些項目的腳手架工具，代碼生成工具等

基礎庫項目布局

每個公司都應該為不同的微服務建立一個統一的kit基礎包工具集。 基礎庫tookit為一個獨立的項目，公司級建議只有一個，按照功能來拆分會帶來不少的管理工作，因此建議并整合

kit包應該具備的特點

• 統一
• 標準庫方式布局
• 高度抽象
• 支持插件

例如下面的布局

|--cache
|    |--memcache
|         |--test
|    |--redis
|         |--test
|--conf
|    |--dsn
|    |--env 
|    |--flagvar
|    |--paladin
|          |--apollo
|               |--internal
|                     |--mockserver
|--container
|    |--group
|    |--pool
|    |--queue
|         |--aqm
|--database
|    |--hbase
|    |--sql
|    |--tidb
|--echo
|    |--types
|--log
|    |--internal
|         |--core
|         |--filewriter
|

應用程序項目布局

/api

API協議定義目錄， xxapi.proto protobuf文件以及生成go的文件，我們通常把api文檔定義在proto 文件中描述

/configs

配置文件模板或者默認配置

/test

額外的外部測試應用程序和測試數據，你可以隨時根據需求構造測試目錄，對于較大的項目，有一個數據子目錄是有意義的，例如你可以使用/test/testdata(如果你需要忽略目錄中的內容）請注意，Go還會以“.”或者“_”開頭的目錄或者文件，因此在如何命名測試數據目錄方便，有著很大的靈活性。

不應該包含/src目錄

有些Go項目確實有src目錄，這是因為開發人員通常有Java的開發背景。

/internal

/biz

業務邏輯的組裝層，類似DDD中的domain，

/data

業務數據訪問，包含cache和db等封裝，實現了biz的repo接口，我們可能會把data和dao混合在一起，data偏重業務的含義，他所做的是將領域對象重新拿出來，我們去掉了DDD的infra層，

/service

實現了api定義的服務層，類似DDD的applocation層，處理DTO到biz領域實體的轉換，（DTO->DO）同事協同個類biz交互，但是不應該處理復雜邏輯

布局示意圖

|--api
|--configs
|--test
|--internal
|       |--biz
|       |--data
|       |--service

數據流向