image.png
注意我们的表述是这样的：主语+定语，如“订单已创建”。
这里又引出DDD中的另一个重要的概念——领域事件。
领域事件（Domain Event），是领域专家关心的，在业务上真实发生的事件，这些事件对系统会产生重要的影响，如果没有这些事件的发生，整个业务逻辑和系统实现就不能成立。我们可以通过领域事件对过去发生的事情进行溯源，因为过去所发生的对业务有意义的信息都会通过某种形式保存下来。领域事件在技术实现过程中可以被实现为专门的事件类，便于 实现事件驱动设计（Event Driven）。常见的影响有：
- 对内产生了某种数据 触发了某种流程或事情 状态发生了某种变化；
- 对外发送了某些消息；
- 规则（Policy），是对分支条件或复杂业务规则的抽象，目的是通过降低分支复杂度聚焦主要业务流程，未来在技术实 现时可能是一些分支条件，也可能应用适合的设计模式。
场景分析：是从用户操作视角出发，根据业务流程或用户流程，采用用例和场景分析方法，探索领域中的典型场景，找出领域事件、实体和命令等领域对象，支撑领域建模的过程。
比如电商业务中一个非常重要的参与者是C端用户，C端用户在电商业务中会去下单、去支付、去收货、去申请退款等等，我们就可以按照业务流程，一步一步搜寻用户业务操作流程中的关键领域事件。事件风暴的参与者要尽可能地遍历所有业务细节，充分发表意见，不要遗漏业务要点，我们把识别出来的领域事件写到贴纸上，贴到墙上，比如这个例子中我们用橙色来标注领域事件。
三、识别命令
前面第二步我们识别出了部分领域事件，那么这些事件是谁触发的呢？触发的动作是什么呢？这就是我们下面要进行的工作：识别命令。
命令可以理解为不同角色用户在界面上面的操作，比如“添加商品”，“编辑库存”，“提交订单”等； 有些命令可能产生多个事件，可以将他们用箭头联系起来; 在进行这个过程中，我们也需要将角色，通过不同的颜色标示出来，如本例中我们用蓝色来标识命令，黄色标识角色。
image.png
四、提取领域对象
从命令和领域事件中提取产生这些业务行为的业务对象，即实体。一个简单的做法是把领域事件中的名词都提取出来，如“商品已创建”中的“商品”、“订单已创建”中的“订单”、“库存已锁定”中的“库存”等都是领域对象，我们继续用黄色贴纸来标识这些实体。
image.png
实体（Entity）：在DDD的领域模型中有这样一类对象，它们拥有唯一标识符，并且它们的标识符在历经各种状态变更后仍能保持一致，对这些对象而言，重要的不是属性，而是其延续性和标识，这种对象的延续性和标识会跨越甚至超出软件的生命周期，这样的对象就是实体对象。比如订单，每个订单都会有一个唯一且不变的标识——订单号，不管订单的状和属性怎么变化，订单还是那个订单，它的生命周期会贯穿甚至超出整个电商业务。
值对象（Value Object）：值对象是通过对象属性值来识别的对象，它将多个相关属性组合为一个概念整体，用于描述领域的某个特定方面，并且是一个没有标识符的对象。
五、构建聚合
实体和值对象都只是个体化的业务对象，它们所表现出来的是个体的行为和能力。在领域模型中我们需要一个这样的组织，将这些紧密关联的个体对象聚集在一起，按照组织内统一的业务规则共同完成特定的业务功能，因此就有了聚合的概念。
在DDD中，聚合是一组紧密相关的领域对象，其目的是要确保业务规则在边界内的不变性，聚合根具有全局标识，所有对聚合内对象的修改，都只能通过聚合根进行，聚合帮助我们简化了复杂的对象网络，逐步做到“高内聚，低耦合”。
从技术的角度可以这么理解，聚合是由业务和逻辑紧密关联的实体和值对象组合而成的。聚合内数据的修改必须由聚合根统一组织，以确保每次数据修改都是按照聚合内统一的业务规则来完成，聚合是数据修改和持久化的基本单元。
比如订单是个聚合，它是由订单基本信息、商品信息、地址信息、发票信息等多个实体组成的，在订单聚合内每次修改商品数据时，它们都必须符合订单聚合的业务规则：“订单总金额等于所有商品明细金额之和”，违反了这个规则就会出现聚合数据不一致等诸多问题。
image.png
六、划定限界上下文
限界上下文（Boundary Context），是业务上下文的边界，在该边界内，当我们去交流某个业务概念时，不会产生理解 和认知上的歧义（二义性），限界上下文是统一语言的重要保证。
关于限界上下文有一个非常形象的定义：
细胞之所以会存在，是因为细胞膜定义了什么在细胞内，什么在细胞外，并且确定了什么物质可以通过细胞膜
一个聚合可能是最小颗粒度的界限上下文，同时，我们常合并业务相关性很高的聚合。
image.png
在未来的技术实现中，应当尽可能避免两个在概念上容易混淆的限界上下文内的业务需求，被同一个团队开发和维护。
七、梳理限界上下文依赖关系
通过分析依赖关系，提前识别依赖矛盾，减少低级设计错误的手段。每一个限界上下文都不会带有全量信息，那么补充信息的来源方向就是依赖方向，或者叫“知道（known）”的方向（我需要知道它的存在）
操作步骤：
- 集体分析和讨论，并利用带箭头的实线，以依赖方向为箭头方向，绘制不同限界上下文间的依赖关系。
- 若出现以下依赖关系，需要思考是否存在未澄清的问题：
a. 双向依赖：上下文之间缺少一层未被澄清的上下文，或者两个上下文其实可被合为一个；
b. 循环依赖：任何一个上下文发生变更，依赖链条上的上下文均需要改变；
c. 过长的依赖：自身依赖的信息不能直接从依赖者获取到，需要通过依赖者从其依赖的上下文获取并传递，依赖链 路过长，依赖链条上的任何一个上下文发生变更，其链条后的任何一个上下文均可能需要改变；
image.png
【另附】限界上下文之间的映射关系主要有下面这几种：
- 合作关系（Partnership）：两个上下文紧密合作的关系，一荣俱荣，一损俱损。
- 共享内核（Shared Kernel）：两个上下文依赖部分共享的模型。
- 客户方-供应方开发（Customer-Supplier Development）：上下文之间有组织的上下游依赖。
- 遵奉者（Conformist）：下游上下文只能盲目依赖上游上下文。
- 防腐层（Anticorruption Layer）：一个上下文通过一些适配和转换与另一个上下文交互。
- 开放主机服务（Open Host Service）：定义一种协议来让其他上下文来对本上下文进行访问。
- 发布语言（Published Language）：通常与OHS一起使用，用于定义开放主机的协议。
- 大泥球（Big Ball of Mud）：混杂在一起的上下文关系，边界不清晰。
- 另谋他路（SeparateWay）：两个完全没有任何联系的上下文。
八、划分问题子域建立服务地图
操作步骤
- 根据“每一个问题子域负责解决一个有独立业务价值的业务问题”的视角出发，可以通过疑问句的方式来澄清和分析子域 需要解决的业务问题，例如“如何进行库存管理？（英文描述类似How to…?）”。
- 利用虚线，将解决同一个业务问题的限界上下文以切割图像的方式划在一起，并以“XXX子域”的形式对每个子域进行命 名。
- 根据三种类型的子域定义，共同结合业务实际（或者参考设计思维中的电梯演讲），确定每个子域的子域类型。
要点提示：
● 问题子域和限界上下文是完全不同的两个维度，问题子域解决的是问题澄清和优先级排序问题，限界上下文解决的是业务边界识别和统一语言的问题，所以在概念上其实不存在先后关系和包含关系，将两张图放在一起，是为了能够方便设 计和分析，可以理解为两张图的“叠加”或“映射”。
● 对于问题子域和限界上下文的映射关系，业内存在争论（是一对多关系还是多对多关系），经过大量的实践，结合可操 作性和理解上的便易性，我们刻意地选择和约定以下的映射关系：
○ 一个子域可以包含多个限界上下文
○ 一个限界上下文不应跨越多个子域 对于子域类型的判断，会随着视角的切换而有所变化，例如从全局视角识别的支撑域，从该支撑域所负责开发的团队视 角来看，该域则属于这个团队的核心域。
● 可以先识别核心域，再识别通用域，这样的话最后剩下的就全都是支撑域。
image.png
到这里我们就完成了电商领域模型的构建的事件风暴实践了。
