DDD领域实践

https://domain-driven-design.org/zh/ddd-concept-reference.html

1）适配层（Adapter Layer）：负责对前端展示（web，wireless，wap）的路由和适配，对于传统B/S系统而言，adapter就相当于MVC中的controller；

2）应用层（Application Layer）：主要负责获取输入，组装上下文，参数校验，调用领域层做业务处理，如果需要的话，发送消息通知等。层次是开放的，应用层也可以绕过领域层，直接访问基础实施层；

3）领域层（Domain Layer）：主要是封装了核心业务逻辑，并通过领域服务（Domain Service）和领域对象（Domain Entity）的方法对App层提供业务实体和业务逻辑计算。领域是应用的核心，不依赖任何其他层次；

4）基础实施层（Infrastructure Layer）：主要负责技术细节问题的处理，比如数据库的CRUD、搜索引擎、文件系统、分布式服务的RPC等。此外，领域防腐的重任也落在这里，外部依赖需要通过gateway的转义处理，才能被上面的App层和Domain层使用。

在DDD中有一个很棒的解耦设计思想——防腐层（Anti-Corruption），简单说，就是应用不要直接依赖外域的信息，要把外域的信息转换成自己领域上下文（Context）的实体再去使用，从而实现本域和外部依赖的解耦。perf docs refactor build

• executor
• model entity
• mapper

BFF,即 Backend For Frontend(服务于前端的后端) 也就是 adapter 层

调用链路

• front - service - dao
• front(controller) - application(service) - domain(service) - remote(transferData/Service) – feign
• front - application - domain - remote

DDD中的界限上下文完美匹配微服务要求, 可以将限界上下文理解为一个微服务进程

设计领域模型的一般步骤如下：

1. 根据需求划分出初步的领域和限界上下文，以及上下文之间的关系；
2. 进一步分析每个上下文内部，识别出哪些是实体，哪些是值对象；
3. 对实体、值对象进行关联和聚合，划分出聚合的范畴和聚合根；
4. 为聚合根设计仓储，并思考实体或值对象的创建方式；
5. 在工程中实践领域模型，并在实践中检验模型的合理性，倒推模型中不足的地方并重构。

战术设计则关注更具体使用建模工具来细化上下文。

现实世界中，领域包含了问题域和解系统。一般认为软件是对现实世界的部分模拟。在DDD中，解系统可以映射为一个个限界上下文，限界上下文就是软件对于问题域的一个特定的、有限的解决方案。

方案

顶层:

• domain 领域服务层, 高度内聚只关注领域内的事, 关注数据模型多一些, 桥接在 应用服务层和数据层之间
• application 应用服务层, 关注领域模型多一些
• infrastructure 基础设施层, 代表支撑, 对业务无感知
• surface 用户表示层 和 gateway 网关层, 承接前端适配以及渲染、聚合数据的分层, 无核心业务, 主要是准入校验以及参数模型转换

应用服务层面向功能定义, 将指令转化为领域层所需的输入模型即可;
业务规则、业务细节、实现等复杂过程都应该在领域层实现

值对象的设计

没有 id, 不会被级联更新

DDD 引入值对象是希望实现从 数据建模为中心 向 领域建模为中心 转变，减少数据库表的数量和表与表之间复杂的依赖关系，尽可能地简化数据库设计，提升数据库性能

• 值对象的设计, 减少了从表, 是一种非范式的设计
• 值对象在数据库持久化方面简化了设计，它的数据库设计大多采用非数据库范式，值对象的属性值和实体对象的属性值保存在同一个数据库实体表中。值对象嵌入到实体表的方式:

1. 属性嵌入
2. 序列化大对象 (JSON)

• 如果值对象使用不当，它的优势就会很快变成劣势

实体对象

实体对象大多是一对一的, 有些场景为了避免数据库联表查询，提升系统性能，会将 客户 (customer) 和 账户 (account) 两类数据保存到同一张表中. 客户和账户两个实体根据需要从一个持久化对象中生成，这就是多对一的场景

(END)