在项目目录执行
protoc --go_out=plugins=grpc:interfaces/proto interfaces/proto/*.proto
在interfaces/proto目录下生成xxx.pb.go文件
在项目目录执行 go mod tidy, 下载依赖包
在项目目录执行 go run main.go, 启动项目
Interfaces 的代码目录结构有:assembler、dto 和 façade 三类
- Assembler: 实现 DTO 与领域对象之间的相互转换和数据交换。一般来说 Assembler 与 DTO 总是一同出现。
- Dto: 它是数据传输的载体,内部不存在任何业务逻辑,我们可以通过 DTO 把内部的领域对象与外界隔离。
- Facade: 提供对外的接口,用户请求通过一个或多个应用服务进行处理。
Application 的代码目录结构有:event 和 service
- Event(事件):这层目录主要存放事件相关的代码。 它包括两个子目录:publish 和 subscribe。前者主要存放事件发布相关代码,后者主要存放事件订阅相关代码(事件处理相关的核心业务逻辑在领域层实现)。
- Service(应用服务):这层的服务是应用服务。 应用服务会对多个领域服务或外部应用服务进行封装、编排和组合,对外提供粗粒度的服务。应用服务主要实现服务组合和编排,是一段独立的业务逻辑。可以将所有应用服务放在一个应用服务类里,也可以把一个应用服务设计为一个应用服务类,以防应用服务类代码量过大。
Domain 是由一个或多个聚合包构成,共同实现领域模型的核心业务逻辑。聚合内的代码模型是标准和统一的,包括:entity、event、repository 和 service 四个子目录。
- Aggregate(聚合): 它是聚合软件包的根目录,可以根据实际项目的聚合名称命名,比如权限聚合。
在聚合内定义聚合根、实体和值对象以及领域服务之间的关系和边界。聚合内实现高内聚的业务逻辑,它的代码可以独立拆分为微服务。
以聚合为单位的代码放在一个包里的主要目的是为了业务内聚,而更大的目的是为了以后微服务之间聚合的重组。聚合之间清晰的代码边界,可以让你轻松地实现以聚合为单位的微服务重组,在微服务架构演进中有着很重要的作用。
- Entity(实体): 它存放聚合根、实体、值对象以及工厂模式(Factory)相关代码。
实体类采用 充血模型,同一实体相关的业务逻辑都在实体类代码中实现。跨实体的业务逻辑代码在领域服务中实现。
-
Event(事件): 它存放事件实体以及与事件活动相关的业务逻辑代码。
-
Service(领域服务): 它存放领域服务代码。
一个领域服务是多个实体组合出来的一段业务逻辑。你可以将聚合内所有领域服务都放在一个领域服务类中,你也可以把每一个领域服务设计为一个类。如果领域服务内的业务逻辑相对复杂,我建议你将一个领域服务设计为一个领域服务类,避免由于所有领域服务代码都放在一个领域服务类中,而出现代码臃肿的问题。领域服务封装多个实体或方法后向上层提供应用服务调用。
- Repository(仓储): 它存放所在聚合的查询或持久化领域对象的代码,通常包括仓储接口和仓储实现方法。为了方便聚合的拆分和组合,我们设定了一个原则:一个聚合对应一个仓储。
Infrastructure 的代码目录结构有:config 和 util 两个子目录
- Config: 主要存放配置相关代码。
- Util: 主要存放平台、开发框架、消息、数据库、缓存、文件、总线、网关、第三方类库、通用算法等基础代码,可以为不同的资源类别建立不同的子目录。
比如创建一个用户的命令:
用户接口层
- Assembler :将 CustomerDTO 转换为 CustomerEntity
- Dto:接收请求传入的数据 CustomerDTO
- Facade:调用应用层创建用户方法
应用层
- Event:发布用户创建事件给其它微服务
- Service:
- 内部服务 -> 创建用户
- 外部服务 -> 创建日志
领域层
- Aggregate:进入用户聚合目录下(如:CustomerAggregate)
- Entity:用户聚合跟
- Event:创建用户事件
- Service:具体的创建用户逻辑,比如用户是否重复校验,分配初始密码等
- Repository:将用户信息保存到数据库