go项目目录

应用项目是包含了很多需要部署在一起的程序集，包括服务、命令行工具和后台运行的程序。每个项目都对应一个含有其所有源代码的仓库，包括所有依赖的三方包。你需要几个应用项目，视情况以你而定，当然是越少越好。

每个应用项目通常包含三个根目录，分别是 cmd, internal, pkg, vendor。在 internal 文件里也会包含 pkg 目录，但是它和 internal 里其他的包有着不同的设计约束。

一个典型的应用项目结构应该是这样的：

paper-code/examples/groupevent
├── cmd/
│   └── eventtimer/
│       └── update/
│       └── main.go
│   └── eventserver/
│       └── router/
│           └── handler/
│           └── router.go
│       └── tests/
│       └── main.go
├── internal/
│   └── eventserver/
│       └── biz/
│           └── event/
│           └── member/
│       └── data/
│           └── service/
│   └── eventpopdserver/
│       └── event/
│       └── member/
│   └── pkg/
│       └── cfg/
│       └── db/
│       └── log/
└── vendor/
│   ├── github.com/
│   │   ├── ardanlabs/
│   │   ├── golang/
│   │   ├── prometheus/
│   └── golang.org/
├── go.mod
├── go.sum

cmd/：项目中的所有你将要编译成可执行程序的入口代码都放在cmd/ 文件夹里，这些代码和业务没有关系。每个程序对应一个文件夹，文件夹的名称应该以程序的名称命名。一般在名称后面加上d 代表该程序是一个守护进程运行。 每个文件夹必须有一个main包的源文件，该源文件的名称也最好命名成可执行程序的名称，当然也可以保留main文件名。

internal/：在go语言中，变量，函数，方法等的存取权限只有exported(全局)和unexported(包可见，局部)2种。在项目中不被复用，也不能被其他项目导入，仅被本项目内部使用的代码包即私有的代码包都应该放在internal文件夹下。。该文件夹下的所有包及相应文件都有一个项目保护级别，即其他项目是不能导入这些包的，仅仅是该项目内部使用。

internal/pkg/：在同一个项目中不同程序需要访问，但又不能让其他项目访问的代码包，需要放在这里。 这些包是比较基础但又提供了很特殊的功能，比如数据库、日志、用户验证等功能。

pkg/：如果你把代码包放在根目录的pkg下，其他项目是可以直接导入pkg下的代码包的，即这里的代码包是开放的，当然你的项目本身也可以直接访问的。

vendor/：vendor文件夹包含了所有依赖的三方的源代码，它是go项目最早的依赖包的管理方式。目前大都用的go mod的依赖包管理，相对vendor，能指定版本，并且你不用特意手动下载更新依赖包，通过正常的go build, go run命令会自动处理。这样会减少项目本身的容量大小。你可以用命令 go mod vendor来创建你项目的vendor目录。如果你项目中既要用到之前的vendor,又要用到go mod，你可以使用 -mod=vendor参数进行编译，但是在go1.14就不用了，当你用go build时，会自动检查项目根目录下有无vendor，并进行编译。

面向包的设计和验证

面向包设计的准则可以验证项目中包设计的是否合理，下面这些步骤可以帮你发现包设计的问题。

包的位置

• kit 被不同应用项目导入的基础包
• cmd 支持编译不同二进制程序的包，比如Restful路由程序，需要相关router, handler包和main入口包。
• internal 项目内部使用的包，包括crud, service(facade)和业务逻辑的包。
• internal/pkg 为本项目内部使用的基础包，包括数据库、认证和序列化等操作的包。
• pkg 其他项目可以访问pkg的代码包

依赖包导入

• 根据业务合理设计包的粒度。

• 在一个包中导入另一个包中的类型，是不合适的。 go源码里面的网络方面的Request, Response, Header等都在http包下面

  go的设计本身不建议建一个model模块，里面全是一个个结构体。因为这样设计，让其他人看代码，可能不知道这些结构体在哪被使用，修改了结构体，也不知道影响面有多大。

• 在同一个目录级别下的包互相导入，是不合适的。

  go更多是按照功能职责进行包的设计，所以同一目录级别下的包是不能互相导入的。除非你采用了在其他语言的架构分层是可以导入的，但也仅限上层可以导入下层的代码包，比如服务层、展现层、业务逻辑层、数据持久化层。

• 如果真有上面的需求

  请检查你对领域知识的理解、领域模型设计和包的设计。

  如果情非得已，那么将被导入的包移动到你的包里面。

• cmd/可以导入其他目录中的代码包。

• internal/中的包不能导入cmd/中的包。

• internal/pkg/中的包不能导入cmd/, internal/中的包。

• pkg/中的包不能导入cmd/, internal/中的包。