本文主要是介绍【领域驱动设计 打通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 中，操作用“操作名 + 括号”的方式表示，括号中可以写参数
实体多关联【标记】
两个实体之间，可以有多个关联。不同的关联代表不同含义，数量关系也可以不同，可以用角色名来区分
- 员工与项目的多对多关系：一个员工（角色为项目成员）可以被分配到多个项目上，一个项目上又可以有多个员工
- 员工与项目的一对多关系：一个员工（角色为项目经理）可以被分配到多个项目上，一个项目只能有一个项目经理
拆分多对多关联【技巧】
某些情况下我们需要拆分多对多关联为两个一对多关联，一般有如下三种情况：
- 关联实体自身也有值得关注的属性【store_with_coop】 商户中的各种实体关系表设计的考虑，独有的包括关系的建立时间、断开时间，关系的状态等
- 关联实体本身也有业务关注的独立的含义的时候（常常表现为在业务的术语里面有）
- 多对多关系存在业务规则时，需要拆分出来一个承载的关联实体
例如项目管理有一个关于投入百分比的规则，那么投入百分比（关联实体自身的属性）这个属性应该记录在哪个实体上呢？这个百分比既不能记录在员工实体上，也不能记录在项目实体上
于是原来的项目成员角色演变成了一个独立的实体，来表达员工和项目之间的多对多关联。预计投入百分比也就自然放在这个实体里面了。注意，这时候，员工和项目成员之间的关联是一对多，项目和项目成员之间也是一对多。
3 将领域对象划分模块
当实体和关联复杂化后，就会让我们的认知过载，解决这一问题的方法就是“模块化”。也就是说，把模型中的业务概念组织成若干高内聚的模块（module），而模块之间尽量低耦合，在 UML 中，可以用包来表示模块，包的内部可以包含实体，也可以包含另外的包
宏观层面我们可以明确大致包间的依赖关系，在 UML 中带箭头的虚线表示依赖（dependency）关系，箭头由依赖方指向被依赖方，例如项目管理依赖组织管理
领域建模的产出
领域建模的产物主要有两个，一个是统一语言词汇表，一个是事件风暴时的业务规则表的继续完善。
UL词汇表
把事件风暴和领域模型中重要的词汇列成表，这么做主要有两个目的：
- 我们需要通过词汇表来规范领域模型中的词汇
- 可以用于后续编程中的命名。按照 DDD 的要求，程序中的各种命名也需要统一，并且需要与领域模型中保持一致
业务规则表
我们在做事件风暴时就开始识别业务规则了，在领域建模中又识别出了更多的规则，所以现在我们需要把这些规则补充到业务规则表
总结一下
同事件风暴一样领域建模也是在模型建立阶段，但更进一步的，领域建模不仅要对业务进行直观模拟，更要经过提炼，形成浓缩的知识，使模型中的知识不再停留在业务的表面，而是深入到业务的本质，进而加入技术视角选择最合适的建模方案。可以理解为是对事件风暴的技术性加工，使用UML图的一些标记例如：注释、约束、多重性、自关联、多关联、角色以及一些技巧如：多对多关联拆分、抽象化实体、模块化来进行领域建模。最后完善业务规则表建立UL词汇表。一个比较深的体会是对于多对多关联拆分的考虑，例如业务事件阶段的【门店、合作】以领域名词的形式候选为实体，在领域建模阶段明确其多重性为多对多关系（一个合作可以有多个门店，附加时间维度一个门店不同时候也可以属于不同合作），但门店的合作包含其特有的合作周期和签约信息，这部分信息放到合作还是门店都不合适，于是需要增加关联实体【门店合作信息】将多对多关联拆分来记录关联特有的属性。
这篇关于【领域驱动设计 打通DDD最小闭环】领域建模的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
