领域驱动设计

1. 基本概念

1.1 模块

• 模块是DDD中明确提到的一种控制限界上下文的手段。
• 我的理解就是模块是微服务拆分单元
• 对于模块内的组织，一般是按照领域对象，领域服务，领域资源库，防腐层等组织方式定义的

1.2 领域对象

• 对应之前设计中的实体对象，但是与以往的仅有getter，setter的实体对象不同，领域对象具有了行为，对象更加丰满。
• 同时对比将这些逻辑写在服务内（如mvc的service层中），领域功能的内聚性更强，职责更加明确
• 领域服务调用领域对象，如果领域对象不稳定，可以将领域对象抽离出接口，领域服务依赖抽离出的接口

1.3 资源库

• 领域对象需要资源存储。以前我们是通过ORM直接映射。只适用于关系型数据库。
• 而且其实存储的手段有很多种，如关系型数据库，分布式缓存，本地缓存，非关系型数据库。我们将这些统一称为资源库。
• 所以我们需要提供对领域的存储和访问进行统一管理的对象。（复用，接口抽象化）
• 资源库对外的整体访问由Repository提供，它聚合了各个资源库的数据信息，同时也承担了资源存储的逻辑（如缓存更新机制）。（即由Repository提供一套通用接口操作所有资源库的手段。它将具体实现隐藏）
• 我的理解就是我们可以通过资源库来获取、修改、删除一个领域对象，重点说一下如何通过资源库创建一个领域对象，其实对于复杂的领域对象（聚合许多子对象的对象）的创建,这个过程会交给领域对象工厂来完成，然后返回给资源库，而资源库再添加上结果缓存等逻辑。总结就是将对象的装配工作交给工厂。

1.4 防腐层

• 在一个上下文中，有时候需要对外部上下文进行访问，通常会引入防腐层的概念来对外部上下文的访问进行一次转义。
• 考虑引入防腐层的情形
  • 需要嫁给你外部上下文中的模型翻译成本地上下文理解的模型（rpc）
  • 不同上下文之间的团队协作关系，如果是供奉者关系，建议引入防腐层，避免外部上下文的变化对本地上下文的侵蚀。
  • 该外部访问在本地上下文中使用广泛，为了避免后续对其改动会影响返回很大。
  • 说白了就像用外观模式封装了对外部上下文的操作，只提供了使操作更方便的接口。
• 如果内部多个上下文对外部上下文需要访问，那么可以考虑将其放到通用上下文中。

1.5 领域服务

• 已经将领域行为封装到领域对象中了
• 已经将资源管理行为封装到资源库中了
• 已经将对外部上下文的交互行为封装到防腐层中去了
• 所以领域服务则就专注于通过串联领域对象，资源库和防腐层等一系列的对象的行为，对其他上下文提供交互的接口
• 如果还需要与用户打交道，则它还负责接收用户请求，返回响应。

2. 设计

2.1 领域对象持久化

• 插入一条记录就是创建一个领域对象
• 更新一条记录就是根据key值去修改相应的领域对象
• 删除数据则是摧毁这个领域对象
• 领域对象持久化存储的设计思想
  • 将暂时不使用的领域对象从内存中持久化到磁盘中
  • 再次使用时，根据key值到数据库中查找该记录
  • 然后将其恢复成领域对象，应用程序就可以继续使用它
  • 其实这些无关具体数据库，不一定是关系数据库

2.2 如何设计领域对象

• 领域对象可以有继承关系（但是关系型数据库中不存在继承关系，所以领域对象设计转换为关系型数据库设计需要有特定的方案）
• 关系型数据库的一对多设计，如果是组合关系（部分不能脱离整体），则这设计为一个领域对象（更像nosql设计）。