Go整洁架构设计——目录结构基本布局

前言

---

       随着项目的代码量在不断地增长，不同的开发人员按自己意愿随意布局和创建目录结构，项目维护性就很差，代码也非常凌乱。良好的目录与文件结构十分重要，尤其是团队合作的时候，良好的目录与文件结构可以减少很多不必要的麻烦。项目目录结构规范的的本质是提高了代码的可读性，最终目的是提高团队协作效率，降低工程维护成本。

      我们知道 java 项目结构是请求达到路由层控制器 controller，然后 controller 会去调用 service 层逻辑代码，然后 service 层会去调用 dao 层的接口方法，其实 dao 层都是以接口的形式提供，然后这些接口里头的都是操作数据库的方法，然后与 dao 层对应着的有一个 mapper，mapper 是以 xml 形式提供的，与 dao 层中的接口相对应，xml 中实际就是实现了 dao 接口中的这些具体方法，xml 中会与指定的 dao 接口中指定的方法进行绑定，xml 中会去写 sql 逻辑。具体请看架构师技能1：Java工程规范、浅析领域模型VO、DTO、DO、PO、优秀命名

  

一、Go语言自身项目的基本结构

---

首先我们先看Go语言自身项目的基本结构。

Go项目的项目结构自1.0版本发布以来一直十分稳定，直到现在Go项目的顶层结构基本没有大的改变。go项目大致结构如下，GitHub - golang/go: The Go programming language

$ tree -LF 1 ~/go/src/github.com/golang/go
./go
├── api/
├── doc/
├── lib/
├── misc/
├── src/

├── test

├── PATENTS
├── LICENSE
├── CONTRIBUTING.md
└── README.md

作为Go语言的“创世项目”，其项目结构的布局对后续的其他Go语言项目具有重要的参考意义，尤其是早期Go项目中src目录下面的结构，更是在后续被Go社区作为Go应用项目结构的模板被广泛使用。我们以早期的Go 1.3版本的src目录下的结构为例：

$ tree -LF 1 ./src
./src
├── all.bash*
├── all.bat
├── all.rc*
├── clean.bash*
├── clean.bat
├── clean.rc*
├── cmd/
├── lib9/
├── libbio/
├── liblink/
├── make.bash*
├── make.bat
├── Make.dist
├── make.rc*
├── nacltest.bash*
├── pkg/
├── race.bash*
├── race.bat
├── run.bash*
├── run.bat
├── run.rc*
└── sudo.bash*

src目录下面的结构三个特点：

1）代码构建的脚本源文件放在src下面的顶层目录下；

2）src下的二级目录cmd下面存放着go工具链相关的可执行文件（比如：go、gofmt等）的主目录以及它们的main包源文件；

3）src下的二级目录pkg下面存放着上面cmd下各工具链程序依赖的包、go运行时以及go标准库的源文件

在Go 1.3版本以后至今，Go项目下的src目录中发生了几次结构上的变动：

Go 1.4版本中删除了Go源码树中src/pkg/xxx中pkg这一层级目录而直接使用src/xxx；

Go 1.4版本在src下面增加internal目录，用于存放无法被外部导入仅Go项目自用的包；

Go 1.6版本在src下面增加vendor目录，但Go项目自身真正启用vendor机制是在Go 1.7版本中。vendor目录中存放了go项目自身对外部项目的依赖，主要是golang.org/x下的各个包，包括：net、text、crypto等。该目录下的包会在每次Go版本发布时做更新；

Go 1.13版本在src下面增加了go.mod和go.num，实现了go项目自身的go module迁移，go项目内所有包被放入名为std的module下面，其依赖的包依然是golang.org/x下的各个包

// Go 1.13版本go项目src下面的go.mod
module std
 
go 1.12<