该项目布局主要参考 project-layout 形成的,对 project-layout 某些描述不清的模块进行进一步描述,和对某些模块详细配置不清楚的模块进一步扩展示例。
项目布局推荐 Go程序目录.
├── cmd
├── internal
└── pkg
server application目录
/api
该目录用来存放 OpenAPI/Swagger 规则说明, JSON 格式定义, 协议定义文件等。也有可能用来存放具体的对外公开 API.
web application 目录 /webWeb应用程序特定的组件:静态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工具期望它们的位置(如果可能)。
IaaS,PaaS,系统和容器编排部署配置和模板(docker-compose,kubernetes / helm,mesos,terraform,bosh)。
/test一般用来存放除单元测试、基准测试之外的测试,比如集成测试、测试数据等。
其他目录 /docs设计和用户文档(除了godoc生成的文档之外)。
/tools存放项目的支持工具。请注意,这些工具可以从/pkg和/internal目录导入代码。
/examples应用程序或公共库的示例。
/third_party外部帮助程序工具,分叉的代码和其他第三方工具(例如Swagger UI)。
/githooksgithooks
/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数据库模型,也可以命名为 model
或者 dao
功能类库
/repository数据处理层,DDD模型中命名为 repo
, Kratos 框架中,命名为 biz
biz被理解为业务逻辑的组装层,如果能正确地理解这个概念,就能把握整个框架的分层设计了。我们从两个关键词来理解这个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欢迎分享,转载请注明来源:内存溢出
评论列表(0条)