DDD 分层设计
- 界限上下文实现不同业务领域边界的微服务物理边界的解耦；
- 聚合实现了微服务内不同聚合之间逻辑边界的解耦；
- 通过领域事件和消息中间件，以数据最终一致性的策略，实现了微服务之间的异步调用和服务解耦；
- 通过适当的数据冗余设计，如值对象的业务快照设计，实现了跨微服务不同聚合之间的数据解耦；
- 微服务内通过分层和不同层的职责边界定义，实现微服务内层职责和代码的解耦；
- 微服务代码目录通过聚合目录和分层目录代码边界，实现不同职责代码边界的解耦，有利于微服务架构的演进时代码的组合和拆分；
- 用户接口层通过 facade 接口和数据组装适配，实现了微服务核心业务逻辑与前端应用的解耦；
- 应用服务通过对不同聚合领域服务的组合和编排，实现了同一个微服务内不同聚合的解耦；
- 聚合之间通过聚合根 ID 引用，而不是对象引用方式，完成不同聚合领域对象之间的访问，实现了聚合之间不同领域对象的解耦；
- 仓储模式通过依赖倒置策略，实现了核心逻辑领域与基础资源处理逻辑的解耦；
- 微服务内聚合之间通过事件总线，以数据最终一致性的策略，实现了聚合之间服务同步调用的解耦。
DDD 代码模型
代码目录：
-
interfaces（用户接口层）
-
- assembler（适配器，实现 DTO 与 DO 领域对象之间的相互转换）
- dto（前端应用数据传输的载体）
- facade（封装应用服务，提供较粗粒度的调用接口，或者将用户请求委派给多个应用服务进行处理）
-
application（应用层）
-
- event（事件）
-
-
- publish（事件发布）
- subscribe（事件订阅）
-
-
- service（应用服务，对多个领域服务或其他微服务进行封装、组合和编排，对外提供粗粒度的服务，可以为每个聚合的应用服务设计一个应用服务类）
-
domain（领域层）
-
- aggregate（聚合，根据实际的聚合名称来命名，如 “Person”）
-
-
- entity（实体，存放聚合根、实体和值对象等，如果聚合内部实体或值对象较多，还可以增加一级子目录进行区分）
- event（事件，存放事件实体以及事件活动相关的业务逻辑代码）
- service（领域服务，存放领域服务、工厂服务等代码，可以封装多个实体或方法供上层应用服务调用）
- repository（仓储，仓储模式通常包括仓储接口和仓储实现服务，可以一起完成聚合内 DO 的持久化，或基于聚合根 ID 查询，完成聚合内实体和值对象等 DO 领域对象的数据初始化。仓储还有 PO 对象及持久化实现逻辑，如 DAO。在仓储设计时有一个重要原则，就是一个聚合只能有一个仓储）
-
-
infrastructure（基础层）
-
- config（主要存放配置相关代码）
- util（主要存放平台、开发框架、消息、数据库、缓存、文件、总线、网关、第三方类库和通用算法等基础代码）
-
-
- api
- driver
- eventbus
- mq
-
对于多表关联的复杂查询，由于不需要有领域逻辑和业务规则的约束，不建议放入到领域层的领域模型中，可以通过应用层的应用服务采用传统多表关联的 SQL 查询，也可以采用 CQRS 读写分离的方式完成数据查询操作。
评论区