摘自
https://segmentfault.com/a/1190000021887191
https://segmentfault.com/a/1190000022122201

限界上下文（Bounded Context）

系统内部按照不同业务目的进行划分的「模块」

BC的划分

1. 需要架构师有着丰富的行业知识或者需要一个有些系统分析经验的业务分析人员

2. 一种可行的方法就是参考敏捷的实践
   先划分一个粗略的 BC 模型；
   然后在每个迭代中细化；
   不断的明确每个领域对象的职责；
   提炼业务规则背后的模型。
   通过 code review 和迭代后的会议分析现有 BC 的合理性并加以修改
   需要类似 CI，单元测试等其他敏捷实践的支持，才能保证模型的不断演进

BC的实现

1. 结构

   
   
   image.png
2. BC间Anticorruption Layer(防腐层) 模式
   对外提供基于 Facade 模式的粗粒度接口
   通过 Adapter 将输入的数据适配为 BC 内部服务所需的数据对象
3. 具有相同名称的领域对象在不同 BC 中的实现
   一方面需要通过「统一语言」这一模式，在团队内部(不仅仅是研发团队，还应该包括业务分析团队和使用系统的业务部门)统一对于这两个不同领域对象的理解，避免歧义
   另一方面，更好的做法是给这两个领域对象各自起一个更为恰当的名称，例如 在在「新契约」与「理赔」这两个不同的 BC 中的「保单」，分为IssuedPolicy 与 ClaimPolicy，帮助团队加深理解。

CQRS

Command Query Responsibility Segregation

核心思想

将「命令」（对会引起数据发生变化操作的总称）与「查询」（不会对数据产生变化，只是按照某些条件查找数据的操作）的操作进行分离，然后在两个独立的「服务」（一般是指两个独立部署的应用。在某些特殊情况下，也可以部署在同一个应用内的不同接口上）中实现

架构图

image.png

挑战

• 基础设施
  可靠的消息中间件
  分布式事务中间件
  不同类型的数据存储引擎【比较常见的情况是 Command 端依然使用传统的关系型数据库，但是对于那些比较特殊的查询则使用专门的数据存储】

• 技术能力
  对于事件的支持的设计
  查询模型的设计【依然需要使用领域驱动的思路设计查询接口】
  事务【根本来说是数据的最终一致性问题】