领域建模
描述
领域建模可以理解为对要解决的现实中的业务问题进行归纳、需求分析的一个过程。领域模型是领域类或者是业务实体的可视化展示，可作为是一种将业务人员需求转为技术层面向对象设计的沟通交流工具。（不要和DDD混为一谈啦）
价值和目的
建立开发和业务都能理解的统一语言，建立系统的服务地图，识别应该重点投入的核心领域。
适⽤场景
完成场景识别与流程设计之后，适用需要拆分的遗留系统或需要建模的新系统，通常在详细方案设计阶段进行。
过程步骤
第一步，业务场景分析
根据业务流程或用户旅程，识别出需要重点分析的领域场景。这一步可参考上一篇指南“场景与流程设计”。
第二步，识别关键领域事件
通过头脑风暴的方式，团队成员一起发散寻找核心域中业务关心的事件。将所有事件记在橙色便签上，按时间顺序贴到看板，形成一条或多条团队认可的事件流程。识别事件要点如下：1.根据事件因果关系来识别各自的前置事件和后置事件。2.在识别事件过程中，发现事件流分支；出现分歧和争执的事件；需要强调的事件或对应的领域逻辑的事件需要用粉色便签标记好，重点关注。
[if !supportLists]Ø [endif]事件命名时需要充分沟通交流，提炼出统一语言。如订单已创建,(OrdeCreated)，即业务名称+动词过去时态的形式。
第三步、识别决策和命令
接着以事件为线索进行反推，是可以找到触发事件的命令及命令的发出者的，领域事件触发来源包括：角色（触发事件的人）、策略（触发事件的规则）、外部系统、事件（即事件的当前事件）。以此完善核心子域的领域事件的实际业务场景。如下图所示：
第四步、识别业务实体
接下来要根据决策和领域事件之间的关系找出业务主体。例如：在“订单已创建”的领域事件与“提交订单”决策之间抽象的业务主体有可能是“订单”。这里有两个方式找到实体：
找决策与事件中的名词，并通过上下文场景验证业务概念的合理性。
结合决策和事件，补充并定义聚合根/实体/值对象。
第五步、划分领域事件中核心子域
接下来要将已经识别出的领域事件进一步划分为子域，每个子域对应一个更小的问题域或更小的业务范围。划分出来的多个核心子领域构成整个业务领域中的核心问题域。
第六步、识别限界上下文.
划分核心子领域后，用限界上下文明确模型要解决的问题，每个限界上下文专注于解决某个特定的子域的问题，识别限界上下文的过程方法是基于已有的问题域聚合进行划分，主划分思路如下：
以产品愿景为前提，围绕某个业务价值进行聚合建设。
将业务能力相似的问题域聚合放到一个限界上下文中。
打开问题域聚合，发现问题域中有二义性的部分，将其分解成多个聚合，划分到不同的限界上下文中。
根据组织结构与团队结构，将不同团队所负责的业务能力放到不同的限界上下文中。
考虑技术约束，包括：技术异构与语言异构，非功能需求，技术限制等。
第七步、识别上下文映射
首先识别跨界限上下文之间的相邻事件关系，其次是事件之间是否存在直接触发关系。最后判断：前置事件为下游为D表示依赖方。后置事件为上游U表示被依赖方。完成上下文映射识别后，即可得到领域分析模型。
常见工具
事件风暴：是事件风暴由Alberto Brandolini提出，是一种在领域驱动设计环境中的研讨会格式，可让您快速分析复杂业务领域,完成领域建模的目的方法。
关键技巧
“不忘初心”，在划分核心子领域的时候，以业务价值聚合建设，识别核心域。
“避免分布式单体”如果你想研究篮子，就不要把鸡蛋打碎。同样每个子域对于解决某个特定的问题，如果问题的再分解后，边界更加混乱，建议先不分解。
