该项目布局主要参考 project-layout 形成的，对 project-layout 某些描述不清的模块进行进一步描述，和对某些模块详细配置不清楚的模块进一步扩展示例。
项目布局推荐
Go程序目录
.
├── cmd
├── internal
└── pkg
server application目录
/api
该目录用来存放 OpenAPI/Swagger 规则说明, JSON 格式定义, 协议定义文件等。也有可能用来存放具体的对外公开 API.
web application 目录
/web
Web应用程序特定的组件：静态Web资产，服务器端模板和SPA。
common application目录
/configs
配置文件模板或默认配置。
/init
存放随着系统自动启动脚本，如：systemd, upstart, sysv；或者通过 supervisor 进行进程管理的脚本。
/scripts
存放 build、install、analysis 等操作脚本。这些脚本使得项目根目录的 Makefile 很简洁。
/build
该目录用于存放打包和持续集成相关脚本。将云（AMI），容器（Docker），操作系统（deb，rpm，pkg）软件包配置和脚本放在/build/package目录中。
将CI（travis，circle，drone）配置和脚本放在/build/ci目录中。请注意，某些配置项工具（例如Travis CI）对于其配置文件的位置非常挑剔。尝试将配置文件放在/build/ci目录中，将它们链接到CI工具期望它们的位置（如果可能）。
/deployments
IaaS，PaaS，系统和容器编排部署配置和模板（docker-compose，kubernetes / helm，mesos，terraform，bosh）。
/test
一般用来存放除单元测试、基准测试之外的测试，比如集成测试、测试数据等。
其他目录
/docs
设计和用户文档（除了godoc生成的文档之外）。
/tools
存放项目的支持工具。请注意，这些工具可以从/pkg和/internal目录导入代码。
/examples
应用程序或公共库的示例。
/third_party
外部帮助程序工具，分叉的代码和其他第三方工具（例如Swagger UI）。
/githooks
githooks
/assets
与资源库一起使用的其他资产（图像，徽标等）。
/website
如果不使用Github页面，则在这里放置项目的网站数据。
/internal/app 布局
目录结构
├── command
│ ├── handler
│ └── script
├── component
├── config
├── cron
│ └── job
├── data
├── repository
├── service
└── transport
├── grpc
│ ├── api
│ ├── handler
│ └── middleware
└── http
├── api
├── handler
├── middleware
└── router
/command
命令行功能模块
- handler：
- script：临时脚本
/component
功能组件，如：db, redis 等
/config
配置模型
/cron
定时任务功能模块
/data
modeldao/pkg
功能类库
/repository
repobizbiz被理解为业务逻辑的组装层，如果能正确地理解这个概念，就能把握整个框架的分层设计了。我们从两个关键词来理解这个biz目录的设计：
- 业务逻辑 - 业务逻辑包括但不限于单个对象的增删改查，会处理很多进阶的内容，例如：
1.1. 复合对象操作，如操作对象A后，再操作对象B
1.2. 特殊逻辑，如创建A对象失败时，等待10s后再创建
1.3. 并发策略，如并发访问对象A和对象B - 组装层 - 重点在于组装底层基础的代码，如CRUD，而不是在biz层直接去操作数据库等
整体来说，biz这一层应重点考虑业务逻辑的信息密度，让业务开发者的重点放在这一层，把基础实现往下沉。
/service
业务逻辑层
/transport
- /transport/http/api：swagger 文档
- /transport/http/handler：控制层
- /transport/http/middleware：中间件
- /transport/http/router：路由
参考资料
- project-layout：https://github.com/golang-standards/project-layout