Go项目DDD骨架
DDD理解
-
DDD是领域驱动设计（Domain-Driven Design）的缩写，是一种软件开发的方法论，其目的是以业务领域为中心，通过深入理解业务领域来指导软件系统的设计和实现。
-
DDD强调将软件系统的设计与业务领域的概念紧密结合起来，将业务领域中的各种概念、规则和流程映射到软件系统中，使得软件系统的设计更加符合实际业务需求，从而提高软件系统的质量和可维护性。
-
在DDD中，领域模型是非常重要的概念。领域模型是对业务领域中各种概念、规则和流程的抽象和描述，是软件系统设计的核心。通过领域模型，可以更加清晰地理解业务需求，并将其转化为可执行的软件系统。
-
除了领域模型外，DDD还强调了一些其他的概念和实践，比如限界上下文、聚合、实体和值对象、领域服务等等，这些都是帮助开发人员更好地理解业务领域、设计出高质量的软件系统的工具和方法。
DDD中application、domain、infrastructure、interface作用介绍
DDD（Domain Driven Design）中，通常将应用程序分为四个层次，分别是应用层（Application Layer）、领域层（Domain Layer）、基础设施层（Infrastructure Layer）和接口层（Interface Layer），这些层次各司其职，具体作用如下：
应用层（Application Layer）
应用层是应用程序的顶层，它负责协调各个领域对象来完成应用程序的业务逻辑。在应用层中，通常包含了各种服务、应用程序逻辑和流程控制等。
应用层的主要作用是将领域对象组织起来，协调它们之间的交互和协作，同时也负责处理领域对象之间的事务。它是应用程序的最高层次，对外提供接口以供用户使用。
领域层（Domain Layer）
领域层是应用程序的核心层，它包含了应用程序的业务逻辑和规则。在领域层中，通常包含了各种实体、值对象、聚合根、仓储等。
领域层的主要作用是定义应用程序的业务逻辑和规则，以及维护领域对象的完整性和一致性。它是应用程序的核心，与应用程序的数据结构和实现无关，可以独立于其他层次进行测试和重构。
基础设施层（Infrastructure Layer）
基础设施层是应用程序的基础设施，它包含了与数据访问、网络通信、文件系统、缓存等相关的代码和工具。在基础设施层中，通常包含了各种数据访问对象（DAO）、消息队列、缓存、日志、配置等。
基础设施层的主要作用是提供与底层设施相关的支持和服务，例如数据访问、缓存、日志、配置等。它是应用程序的基础，为上层的应用层和领域层提供支持和服务。
接口层（Interface Layer）
接口层是应用程序的外部接口，它包含了与用户界面、API、消息队列等相关的代码和工具。在接口层中，通常包含了各种控制器、视图、API、消息队列等。
接口层的主要作用是为外部系统提供接口，例如Web界面、API接口、消息队列等。它是应用程序与外部系统进行交互的界面，为上层的应用层和领域层
DDD项目骨架
项目骨架包含了哪些内容？
- 定义了目录层级及职责
- 定义了各层级的包名命名规范、不同包名下的文件命名规范
- 定义了特定type、变量、函数等的命名规范
| 目录 | 职责 | 规范 |
|---|---|---|
| application | 应用层: 是应用程序的顶层，它负责协调各个领域对象来完成应用程序的业务逻辑 | DDD四层之一，包名不可改 |
| ├── appservice | 存放所有应用服务 | |
| │ ├── {实体名}__checker.go | 围绕这个实体的应用服务 | 如目录名 |
| ├── dto | 存放所有dto | |
| │ ├── {实体名}_dto.go | 入参和出参 | 一个实体文件里会有多个struct，根据其职责来规范命名，便于识别struct的目的。xxxCmd：写接口的入参dtoxxxQry：读接口的入参dto；xxxDTO：出参dto |
| │ ├── {实体名}_dto_conv.go | application层的dto和domain层的entity之间相互转换逻辑 | 如目录名 |
| domain | 领域层:应用程序的核心层，它包含了应用程序的业务逻辑和规则 | DDD四层之一，包名不可改 |
| ├── adapter | 存放访问第三方服务的接口，不包含存储类的资源库访问 | |
| │ ├── exentity | 需要用到的入参出参 | |
| │ ├── {实体名}_adapter.go | 如目录名 | |
| ├── dservice | 存放领域服务 | |
| │ ├── {xx}_ds.go | 如目录名 | |
| ├── entity | 存放实体 | |
| │ ├── {实体名}_entity.go | 如目录名 | |
| ├── repository | 存放资源库的访问接口 | 一个聚合/实体对应一个资源库 |
| │ ├── {实体名}_repo.go | 如目录名 | |
| ├── vo | 存放值对象 | |
| │ ├── {xx}_vo.go | 如目录名 | |
| infrastructure | 基础设施层:应用程序的基础设施，它包含了与数据访问、网络通信、文件系统、缓存等相关的代码和工具 | DDD四层之一，包名不可改 |
| ├── adapter | 存放访问第三方服务的接口实现 | |
| │ ├── {xx}_adapter_impl.go | 如目录名 | |
| ├── build | 编译相关 | |
| │ ├── build.sh | ||
| ├── common | 存放本层的公共逻辑，如http client、数据库连接管理、utility等 | |
| │ ├──{xx}.go | db_conn.go、redis_conn.go | 如目录名 |
| ├── repository | 存放资源库的访问接口实现 | |
| │ ├── {xx}_repo_impl.go | 如目录名 | |
| ├── po | 持久化对象，即数据库表 | |
| │ ├── {xx}_po.go | 如目录名 | |
| │ ├── {xx}_po_conv.go | domain层的entity和infrastructure层的po之间相互转换逻辑 | 如目录名 |
| interface | 接口层:应用程序的外部接口，它包含了与用户界面、API、消息队列等相关的代码和工具 | DDD四层之一，包名不可改 |
| ├── cli | ||
| ├── http | ||
| │ ├── controller | 按实体分文件 | |
| │ ├──middleware | 按中间件分文件，如log.go、bduss.go。中间件指请求进来时需要前置处理的公共逻辑单元 | |
| │ ├── router.go | 如目录名 | |
| │ ├── server.go | 如目录名 | |
| ├── app.go | ||
| ├── config.go | ||
| ├── wire.go | ||
| ├── wire_gen.go | ||
| main.go | ||
| yapi-import.json |
重要规范说明
- 项目目录层级要精简，尽量不超4层。尽量用同一的文件后缀名区分职责和类型，如xx_as.go/xx_entity.go
- 四层之间的依赖关系不能乱
a. 四层不是从上到下的关系，而是类似洋葱结构的环形，从外层向内层。
b. domain是最内层，不依赖其他三层
c. application层和infrastructure层依赖domain层。application可以依赖infrastructure层
d. infrastructure层依赖domain层，domain层和infrastructure层是典型的依赖倒置设计。比如adaptor和repository的接口在domain层，实现逻辑在infrastructure层。
e. interface层是最外层，可以依赖其他三层 - 领域是DDD领域驱动里的灵魂，要和产品一起把业务实体的职责、边界、中英文命名讨论并确定下来，写到需求和设计文档里。代码里的url path、实体名等多种文件命名都需要体现正确的名称。