领域建模的方法
领域建模的⽅法
⼀、领域建模的好处
DDD最⼤的好处是：接触到需求第⼀步就是考虑领域模型，⽽不是将其切割成数据和⾏为，然后数据⽤数据库实现，⾏为使⽤服务实现，最后造成需求的⾸肢分离。DDD让你⾸先考虑的是业务语⾔，⽽不是数据。DDD强调业务抽象和⾯向对象编程，⽽不是过程式业务逻辑实现。重点不同导致编程世界观不同。⾯向对象
封装：Account的相关操作都封装在Account Entity上，提⾼了内聚性和可重⽤性。
多态：采⽤策略模式的OverdraftPolicy（多态的典型应⽤）提⾼了代码的可扩展性。
⼆、如何进⾏领域建模
其实就是如何识别领域，到需要建模的领域有哪些，这⾥有六个⽅法：
2.1 业务流程：
模型是客观存在的，只是你能不能把它画出来。要画出领域模型，它的⽅法是从业务流程⼊⼿，没有到
业务流程很难画出领域模型(不管你⽤什么⽅法，虽然叫法不⼀样，实施流程不⼀样，但有些本质思路是⼀样的，这个⼤家可以⾃⾏体会)。所以，画⼀个领域模型时，不管通过什么途径出其业务流程。任何业务都存在⼀条稳定的业务流程。
在到业务流程后，⽐如优惠券业务，其流程是建券、发券、⽤券，每个流程都会有产物，建券的产物就是券模板(券批次)，发券的产物就是券实例，所以这⾥的产物就是整个业务⾻架，这和四⾊建模中的时序对象⼀样，综合了四⾊建模和事件风暴的⽅法。
1. 出业务主流程：第⼀步是出业务主流程，这是业务的⽣命周期，不管怎么讲，任何业务都有⼀套稳定的业务流程。当接⼿⼀个新
业务时，先不要急着想领域模型，当按照我分享的步骤去分析业务时，领域建模⾃然会⽔到渠成展⽰出来的。类似上⾯的优惠券业务，业务流程就是建券、发券、⽤券。业务主流程每个流程节点都会有⼀个产物出现，这个产物就是业务的⾻架，在这个业务下，它的产物是券批次、优惠券实例。注意，它仅仅是⼀个⾻架，但⾄少到两个关键领域对象。
2. 细分业务主流程：这⼀步是在主流程基础上继续分析⼦流程，主流程能让我们知道整体的业务流程，但还有些细节流程是在⼦流程
建模方法
中，⽐如建券是⼀个⼤流程，那么我们马上会问，这个券长什么样？有哪些关键属性？等，是不是多问⼏个为什么马上让我们就深⼊到业务细节了。再⽐如发券过程，需要经过⼀些检查，如规则检查、风控检查，最后才是发券，这样分析下来，我们对业务掌握得越来越深⼊。上⾯提到我们分析出的两个关键领域对象，此时再从两个⽅⾯考虑：⼀个是其它对象关联，或者包含券模板和优惠券实例；另⼀个是券模板或者优惠券实例包含其它。
3. 抽象：从第⼆步中，我们得到更多具体对象，但此时要进⾏合并整理，并不是直接加到券模板或者优惠券实例关联部分上，这个过程
是不断打磨的过程。上⾯就是领域建模的三步⽅法：出业务主流程、细分业务主流程、抽象。没有任何⾼深的理论、简单朴素的⽅法，⾄于为什么觉得简单，是因为前期铺垫唤醒了你之前的经历，再去做相似的事就会觉得有熟悉感。
2.2 ⽤例建模
1. 识别业务执⾏者：业务执⾏者（businessactor）是在系统之外与业务交互的⼈或组织；业务⼯⼈（businessworker）是在系统内帮
助完成业务处理的服务⼈员或系统。⼀般来说，真正的顾客才是业务系统的执⾏者，如银⾏贷款系统的业务执⾏者为来银⾏办理贷款业务的客户。
2. 识别业务⽤例：业务⽤例是业务单元为业务执⾏者提供的完整价值，需要从业务执⾏者的⾓度对每⼀个业务单元进⾏分析提取业务⽤
例。UML ⽤例图主要由业务⽤例和业务执⾏者构成，通过“业务执⾏者——业务⽤例”的模式来反映业务执⾏者驱动业务⽤例的状况。
3. 描述业务⽤例：对业务⽤例的描述是为了说明各业务⽤例的实现过程。业务⽤例的描述有两种⽅式：⽤例⽂档和UML动态图：如序列
图或活动图。采⽤⽤例⽂档来描述业务⽤例需要遵循⼀个⽤例模板，该模板中⼀般应包括以下信息：⽤例名称、⽤例编号、⽤例的简短描述、⽤例的业务执⾏者、业务⼯⼈、前置条件、后置条件、⽤例的输⼊、输出、⽤例的执⾏过程等。
4. 分析⽅法提取类：依据⽤例描述⽂档出其中所有的名词，将名词作为类和对象的候选者。
5. 定义类的属性和⾏为：属性是类的⼀个描述特征，类的⾏为描述了这个类在系统中所提供的服务。和类的来源⼀样，类的属性和⾏为
也有⼀部分来源于⽤例描述⽂档。⽂档中的形容词作为确定类的属性的线索，动词作为类⾏为（操作）的候选者。
6. 建⽴类之间的关系：出实体类，确定了类的属性和⾏为以后，还需要分析任意两个类之间的关系。类之间的关系主要有四种：泛
化、关联、聚合、依赖。
2.3 事件风暴
事件风暴是⼀项团队活动，领域专家与项⽬团队通过头脑风暴的形式，罗列出领域中所有的领域事件，整合之后形成最终的领域事件集合，然后对每⼀个事件，标注出导致该事件的命令，再为每⼀个事件标注出命令发起⽅的⾓⾊。命令可以是⽤户发起，也可以是第三⽅系统调⽤或者定时器触发等，最后对事件进⾏分类，整理出实体、聚合、聚合根以及限界上下⽂。在整个事件风暴⽅法中，有三个关键要素如下：
事件 -> 某个动作的结果
命令 -> 某个动作
实体 -> 命令的触发者
1. 识别事件和命令：事件你可以理解为⼀个事物所编写出来的最终状态，例如订单已创建，⽀付已完成，商品已发货等即是关键的事
件。⽽命令可以理解为具体的业务功能或操作，⽐如创建订单，检索商品，扣减库存等。可以看到事件和命令的识别和分析中，都可以识别到具体的领域对象。
2. 基于领域对象进⾏聚合：如何进⾏聚合？简单来说仍然是通过识别和梳理出来的共性领域对象进⾏聚合。将对同⼀领域对象的所有命
令和事件都聚合在⼀期。
3. 进⾏上下⽂边界的划分：基于聚合完成的情况进⾏上下⽂边界的划分，这⾥实际上不同的领域对象如果属于同⼀个⼤类的业务场景，
仍然是可以划分到⼀个上下⽂⾥⾯的。也就是不是简单的按聚合完成的领域对象划分上下⽂边界，很多和核⼼领域对象相关的附属对象也需要划分到同⼀个上下⽂的。⽐如电商⾥⾯的订单是⼀个⼤量的领域对象，可以划分为独⽴的上下⽂，但是对应购物车也是我们识别的对象，购物车本⾝同样属于产品订购场景，订单的扩展附属对象，因此需要将购物车也划分到订单上下⽂⾥⾯。
2.4 四⾊建模
四⾊建模法包括：时标型（Moment-Interval）对象；PPT（Party/Place/Thing）对象；⾓⾊（Role）对象；描述（Description）对象，我们建模的次序和重点：
⾸先以满⾜管理和运营的需要为前提，寻需要追溯的事件。
根据这些需要追溯，寻⾜迹以及相应的时标性对象。
寻时标对象周围的⼈／事／物
从中抽象⾓⾊
把⼀些信息⽤描述对象补⾜。
由于在第⼀步中，我们就将管理和运营⽬标做为建模的出发点。因此，整套模型实际上是围绕这些“如何有效地追踪这些⽬标”⽽建⽴的，这样的模型可以保证模型⽀撑企业的运营。四⾊建模法通过将管理和运营⽬标做为建模的出发点，整套模型实际上是围绕这些“如何有效地追踪这些⽬标”⽽建⽴的，这样的模型可以保证模型⽀撑企业的运营，四⾊建模法和别的建模⽅法相⽐，更倾向于作为⼀种分析⽅法，⽽不是设计⽅法，通过将分析得到的领域对象分别归⼊这四类原型，能让我们更加深刻的理解每个对象的职责，以及对象之间的相互关系。
⼀个关键的问题还没有说明：从哪⾥?如果你还记得领域模型是“需求到⾯向对象的桥梁”，那么你肯定⼀下⼦就能想到：从需求模型中，具体来说就是从⽤例中。归纳⼀下域建模的⽅法就是“从⽤例中名词”。当然，到名词后，为了能够更加符合⾯向对象的要求和特点，我们还需要对这些名词进⼀步完
善，这就 是接下来的步骤：加属性，连关系! 最后我们总结出领域建模的三字经⽅法：名词、加属性、连关系。
1. 发现类和对象：尽可能多的出概念类（识别⽅法：概念类分类列表、名词性短语）。概念分类列表：⼈、事物、地点、组织、概
念、事件、规则、抽象名词、交易项⽬、⾓⾊、设备、组织结构（对⽤例进⾏识别：实体、过程中的信息、⾓⾊的输⼊输出、操作设备等）；名词分析法：识别问题域和⽤例描述中的名词和名词性短语作为候选的概念类和属性，从候选项中，摒弃多余的名词，确定最终的对象（注意是作为类还是属性，类可以是⼀种标识、状态和⾏为）
2. 建⽴类之间的关联（关联、继承、依赖）。关联：类之间的某种语义关系包括聚合，组合；继承：⼀般到特殊；依赖：表明⼀个元素
（源元素）的定义或实现依赖另⼀个元素（被依赖元素）的定义或实现
3. 添加类的重要属性（类的语义完整性、类的作⽤、问题域相关特性等）。语法：可见性 属性名：类型 多重性=默认值{特性表}/ [可见
性] 属性名 [：类型] [=初始值]；属性类型是简单的数据类型为佳，如果是复杂概念，考虑是否单独作为
⼀个概念类；任何属性都不表⽰外键，即不应该⽤属性来联系概念类，区别于数据库设计中的外键
2.6 领域驱动建模（DDD）
DDD建模的⼀般步骤：
1. 构建领域知识：软件的最终⽬的是增进⼀个特定的领域。为了达到这个⽬的，软件需要跟要它服务的领域”和谐相处”。所谓和谐相
处，软件需要精确地反应领域概念和知识，以更好的适应变化。因此，软件开发者第⼀步也是最重要的⼀步就是理解领域知识。DDD ⿎励开发者和领域专家⼯作在⼀起，通过交谈和提问，让开发者学习到领域知识，挖掘出领域的关键概念。
2. 创建通⽤语⾔：通⽤语⾔是领域专家和开发团队之间定义的标准的术语。⽬的是把领域知识更完善地传达到软件中。团队在进⾏所有
⽅式的沟通时（⽂字，演讲，图形）都需要采⽤这种⼀致的语⾔。通⽤语⾔需要映射到模型中，映射到代码⾥。做到通⽤语⾔的更改就是对模型的更改，也是对代码的更改。
3. 创建实体：基于通⽤语⾔和领域知识，需要⾸先分辨出实体。实体是领域中需要唯⼀标识的领域概念。如果两个实体所有状态都⼀
样，但标识不⼀样，就是两个不同的实体。实体同样需要属性来描述
4. 创建值对象：值对象是领域中不需要唯⼀标识的领域概念。如果两份对象所有状态都⼀样，我们就认为是同⼀个值对象。值对象也可
以理解为⼀组聚合的属性。例如地址信息，类⽬信息。
三、战略建模和战术建模
战略建模和战术建模，其实是《实现领域驱动设计》最前⾯的内容，位于《如何使⽤本书》部分，当时看的时候并没有很注意，但在前两章的内容中，发现有很多这样的字眼：“团队有⼈花额外的时间去了解战术模式、团队采⽤的是战略模式的建模⽅式。。。”，这就不得不让你回过头看下，什么是战略建模和战术建模？其实，关于这两点，作者并没有很准确的进⾏定义，只是分别描述了这两点内容的关键字，我们来总结⼀下：
战略建模：界限上下⽂（Bounded Context）、上下⽂映射图（Context Mapping）。
战术建模：聚合（Aggregate）、实体（Entity）、值对象（Value Objects）、资源库（Repository）、领域服务（Domain Services）、领域事件（Domain Events）、模块（Modules）。
3.1 战略建模
限界上下⽂：它是⼀个限定边界的环境，在该环境中，每⼀个模型的概念（包括它的属性和操作）都具有特殊的含义。它是战略建模的核⼼，在每⼀个限界上下⽂⾥都共⽤且只有⼀套通⽤语⾔，不存在⼆义性。。在确定⼦域及限界上下⽂后，⼀些容易混淆的概念会逐渐得到清晰的描述，这样可以⽅便开发团队、业务⼈员及客户之间的交流，⽽且还为我们开发时划分项⽬功能提供最直接的依据。
⽽上下⽂映射图：通⽤使⽤框图或代码的⽅式来展现限界上下⽂之间的集成关系。实线连接，表⽰两端的限界上下⽂之间存在联系。线上标注的U/D表⽰上游/下游。通常情况下：上游的限界上下⽂会为下游提供访问接⼝（或服务），下游使⽤⼀个防腐层获取从上游接⼝传过来的数据，然后转化成本限界中使⽤的实体。
3.2 战术建模
回过头来看以上六个⽅法在战略和战术建模中其实都是有应⽤，但是在建模过程中，还是要顺着战略和战术的思路去构建，这样才能做出来⼀个好的设计。DDD是领域驱动设计，⽽不是领域驱动开发，所以我们在开发的时候具体采⽤哪⼀套开发流程，⼜是另外⼀套说法了。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。