【领域驱动设计 打通DDD最小闭环】三 模型的建立-领域建模

本篇BLOG为DDD流程的第二步，在模型的建立阶段，领域专家与技术人员通过领域建模来完成更为细致的模型建立讨论

领域建模的目的

领域建模主要有两个目的：

• 将知识可视化，准确、深刻地反映领域知识，并且在业务和技术人员之间达成一致
• 指导系统的设计和编码，也就是说，领域模型应该能够比较容易地转化成数据库模式和代码实现

不同于事件风暴仅仅追求“形似”，也就是说业务是怎样运作的，事件风暴就怎样反映，领域建模更要“神似”。也就是说，领域建模不仅要对业务进行直观模拟，更要经过提炼，形成浓缩的知识，使模型中的知识不再停留在业务的表面，而是深入到业务的本质，进而加入技术视角选择最合适的建模方案

领域建模的步骤

我们建立领域模型，主要是要识别领域对象（domain object），领域对象之间的关系，以及领域对象的关键属性，必要的时候还要将领域对象组织成模块

1 识别领域对象

什么是领域对象，我们系统中要处理的各种“事物”就是领域对象(可能是领域名词，也可能是名词化的动词)，DDD 中将领域对象又分成实体（entity）和值对象（value object）

我们可以先假定每个领域名词都是一个实体，把它们用UML图的类的符号画出来，例如

实体识别注意事项

实体的识别过程中有两点需要注意一下：

• 领域建模阶段，我们主要关注的是实体和它们之间的关系，所以先不具体描述属性
• 通过后序分析，我们会进一步识别有些名词不是实体，有些要转换成其他形式

也就是用领域名词来当做实体是第一步。

2 识别领域对象关系

领域对象中的关系主要有如下几种：一对一关系，一对多关系，多对多关系，并应用UML的一些表达技巧将这些关系表示出来，业务事件风暴后我们最终形成了如下的领域对象关系UML，这里有很多要点。

实体抽象【技巧】

企业、开发中心、开发组、直属部门，其实都是组织结构中的节点而已，从这一点来说，他们是有共性的，都是组织，所以可以抽象为组织和组织类别两个实体，同样管理员、人事人员的共性都是人员，所以可以抽象为人员和岗位两个实体，用于更灵活的扩展

注释与约束【标记】

可以通过增加注释和约束，使模型中的业务知识更加丰富和准确。其中，约束是一种特殊的注释，它的内容必须以某种形式在代码或数据库中实现。约束也属于我们在之前说的业务规则，需要补充到业务规则表中去

• 在 UML 中，注释用折角的矩形表示，和被注释的实体之间用虚线连接
• 约束的内容用大括号括起来了。在 UML 中，用大括号括起来的内容称为“约束”（constraint）

实体自关联【标记】

一个组织可以有多个组织作为自己的下级；而一个组织只能有一个组织作为自己的上级，在这个自关联的两端，有上级和下级两个词。它们在 UML 里称为“角色”（role），没有角色我们无法明确上下级的多重性

关联多重性【标记】

关联多重性主要表示两个实体之间的数量对应关系，我们通常会更细化一些，例如：

• 0..1表示：一个下级可以没有上级，最多只能有一个上级
• 1..1表示，一个员工最少要属于一个组织，最多也只能属于一个组织
• 0..*表示：一个组织最少有 0 个员工，最多可以有很多员工

识别操作【标记】

操作（operation）在 UML 里也叫方法（method）。对象的属性是静态的值，而操作是动态的逻辑。在 UML 中，操作用“操作名 + 括号”的方式表示，括号中可以写参数

实体多关联【标记】

两个实体之间，可以有多个关联。不同的关联代表不同含义，数量关系也可以不同，可以用角色名来区分

• 员工与项目的多对多关系：一个员工（角色为项目成员）可以被分配到多个项目上，一个项目上又可以有多个员工
• 员工与项目的一对多关系：一个员工（角色为项目经理）可以被分配到多个项目上，一个项目只能有一个项目经理

拆分多对多关联【技巧】

某些情况下我们需要拆分多对多关联为两个一对多关联，一般有如下三种情况：

1. 关联实体自身也有值得关注的属性【store_with_coop】 商户中的各种实体关系表设计的考虑，独有的包括关系的建立时间、断开时间，关系的状态等
2. 关联实体本身也有业务关注的独立的含义的时候（常常表现为在业务的术语里面有）
3. 多对多关系存在业务规则时，需要拆分出来一个承载的关联实体

例如项目管理有一个关于投入百分比的规则，那么投入百分比（关联实体自身的属性）这个属性应该记录在哪个实体上呢？这个百分比既不能记录在员工实体上，也不能记录在项目实体上

于是原来的项目成员角色演变成了一个独立的实体，来表达员工和项目之间的多对多关联。预计投入百分比也就自然放在这个实体里面了。注意，这时候，员工和项目成员之间的关联是一对多，项目和项目成员之间也是一对多。

3 将领域对象划分模块

当实体和关联复杂化后，就会让我们的认知过载，解决这一问题的方法就是“模块化”。也就是说，把模型中的业务概念组织成若干高内聚的模块（module），而模块之间尽量低耦合，在 UML 中，可以用包来表示模块，包的内部可以包含实体，也可以包含另外的包

宏观层面我们可以明确大致包间的依赖关系，在 UML 中带箭头的虚线表示依赖（dependency）关系，箭头由依赖方指向被依赖方，例如项目管理依赖组织管理

领域建模的产出

领域建模的产物主要有两个，一个是统一语言词汇表，一个是事件风暴时的业务规则表的继续完善。

UL词汇表

把事件风暴和领域模型中重要的词汇列成表，这么做主要有两个目的：

• 我们需要通过词汇表来规范领域模型中的词汇
• 可以用于后续编程中的命名。按照 DDD 的要求，程序中的各种命名也需要统一，并且需要与领域模型中保持一致
  

业务规则表

我们在做事件风暴时就开始识别业务规则了，在领域建模中又识别出了更多的规则，所以现在我们需要把这些规则补充到业务规则表

总结一下

同事件风暴一样领域建模也是在模型建立阶段，但更进一步的，领域建模不仅要对业务进行直观模拟，更要经过提炼，形成浓缩的知识，使模型中的知识不再停留在业务的表面，而是深入到业务的本质，进而加入技术视角选择最合适的建模方案。可以理解为是对事件风暴的技术性加工，使用UML图的一些标记例如：注释、约束、多重性、自关联、多关联、角色以及一些技巧如：多对多关联拆分、抽象化实体、模块化来进行领域建模。最后完善业务规则表建立UL词汇表。一个比较深的体会是对于多对多关联拆分的考虑，例如业务事件阶段的【门店、合作】以领域名词的形式候选为实体，在领域建模阶段明确其多重性为多对多关系（一个合作可以有多个门店，附加时间维度一个门店不同时候也可以属于不同合作），但门店的合作包含其特有的合作周期和签约信息，这部分信息放到合作还是门店都不合适，于是需要增加关联实体【门店合作信息】将多对多关联拆分来记录关联特有的属性。