业务与技术沟通的桥梁——领域驱动设计中的领域建模

1,742 阅读6分钟

1.领域建模是什么

领域驱动设计的核心是领域建模,领域建模的生命力体现在为业务人员与技术人员建立了一个桥梁。

同事件风暴一样,领域建模依然重视可视化,直观深刻,可交流,可随时修改,通过可视化建立一致的业务知识理解,共同消化业务知识;阶段性地以统一语言(Ubiquitous Language)为目标,简化认知,统一认知,指导开发;统一语言的建设又会修正领域模型的合理性,循环往复,业务知识逐渐清晰,核心模型被抽象出来。

领域模型创造性地解决了软件分析与设计容易割裂的开发现状,将分析模型中不需要技术人员理解的业务概念,与设计模型中不需要业务人员理解的技术概念的割裂状态进行统一,通过领域模型达成双方都可以理解的业务概念。

领域模型与业务需求关联、与软件实现关联,领域模型的修改就是业务需求的修改、也是软件实现的修改,业务需求修改、软件实现修改也是领域模型的修改,通过这种关联关系建立起业务人员与技术人员的约束关系,探讨业务需求与软件成果有了同频机会,达到业务需求与软件实现的一致性。

2.领域模型与类图

建立领域模型的过程主要包括:

  • 识别领域对象(Domain Object)
  • 识别领域对象之间的关系,领域对象的关键属性与重要操作
  • 组织领域对象模块

这种模型的抽象契合UML的类图设计思想(历史渊源也是如此,从OO演进而来),因此领域建模的可视化就类似于建立类图的过程,设计要素也能与UML得到对应。

2.1 类与关联关系

小步快跑,我们同样不要求一步登天。

最开始,就将上个环节事件风暴聚合的领域名词直接作为实体/类建立。至于实体的属性与操作可能并不会立刻得到,可以再关联关系识别后不断补充。

有了实体之后需要考虑实体之间的关系,这里主要是关联关系包括一对一关联、一对多关联(多对一关联)、多对多关联、自关联。

类图存在较多实体可以进一步分包形成具有依赖关系的包图。

2.2 多重性

关联关系可以通过多重性表达。其他的类图要素我们很熟悉,这里着重介绍下可以包含丰富业务知识的多重性。

多重性(multiplicity)定义了类A有多少个实例可以和类B的一个实例关联,以及类B有多少个实例可以和类A的一个实例关联。

多重性的值表示在特定时刻有效关联的实例数量,比如一两二手车可以经手多个经销商但是某一时刻只能归属于某一个经销商。

  • *代表多也就是值大于等于0
  • 1..*也代表多但是有下限也就是值大于等于1
  • 5表达精确地5,5..10表达5~10这个区间
  • 3,5,7表达精确地3、5、7

多重性的值的上下界可以通过翻译为自然语言来确定,一个关联关系的两个多重性的值也就能够敲定了,比如说这样:

  • 一个类A最多可以对应多少个类B
  • 一个类A最少可以对应多少个类B
  • 一个类B最多可以对应多少个类A
  • 一个类B最少可以对应多少个类A

2.3 注释与约束

注释与约束是对类图的业务知识的补充。在类与关联不能表述完全的就可以借助注释与约束来补充解释。

两者都是通过带折角的矩形绘制,约束通过大括号标记和注释做区分。

3.如何开展领域建模

3.1 识别实体

在事件风暴之后,识别聚合得到了这些领域名词,最开始简单粗暴,我们就直接将这些名词作为实体。很有可能识别是不准确的,不要紧,我们可以快速看到模型并不断迭代。

由此得到实体——布控任务、告警消息、用户和点位。使用类图来绘制表达领域模型。

事件风暴聚合识别举例.png

3.2 识别关联关系

接着寻找实体间的关联关系,关联关系包括一对一关联、一对多关联、多对一关联、多对多关联,以及自关联

系统交付给用户后,用户可以创建布控任务,一个用户可以创建若干个任务,当然也可以不创建,一个任务有且只能由一个用户创建,这样就确定了第一个多重性。在用户类与布控任务类之间建立关联关系,在用户类一侧打上多重性标记*代表可创建的任务数量,在布控任务类一侧打上多重性标记1代表可被创建的用户数。

接着还会想到,在事件风暴开始时的业务知识介绍中,有提到布控任务创建时选择了的推送用户对任务也是可见的。于是,在用户类与布控任务类之间新增了一条关联关系,代表着用户与布控任务之间的可见关联,不同于创建关联,一个布控任务可以被很多用户所见。

简单分析后,几个初步识别的实体之间的关联关系就识别完成了。

领域建模类图关联举例.png

如果关系复杂,还需要进一步抽象关联关系。对于任何多对多关联,总可以通过引入一个表示关联的实体,拆成两个一对多的关联。

3.3 划分模块

进一步,对类图划分模块,形成包图。包图构建的是模块及模块间的依赖(dependency)关系,宏观了解业务组成。

在这个例子中,模块划分及依赖关系是这样的:

领域建模包图依赖举例.png

3.4 完善业务规则记录

建模过程对业务知识的探讨与消化更加深入,许多业务规则也被挖掘出来,事件风暴中的业务规则在建模过程中不断更新。

比如这里就增加了创建布控任务时需要将创建者默认纳入到推送人员当中来。

事件风暴业务规则记录举例.png

3.5 建立统一语言词汇表

经过事件风暴与领域建模,团队对于业务知识具备了初步的共识,达成统一语言。统一语言的作用是简化认知、统一认知、指导开发。 这样,对团队的不同成员不同开发阶段,保证信息的快速高效流通;对于开发而言,程序命名的问题得到解决。

领域建模统一语言词汇表举例.png


参考