好的领域模型应该是什么样子?|今日热门
2022-12-21 21:36:43 来源:

好的领域模型应该长什么样子?

DDD说,领域模型应该是可以准确表达业务需求的模型。


(资料图)

模型和领域模型是两个概念,模型可以是数据模型或服务模型,领域模型是以领域为核心的模型,是对领域知识严格组织和抽象得来的。

那,应该如何描述领域模型呢?

是UML图?还是编程代码?还是一个完整的书面文档?

这些仅仅是表达领域模型的一种载体,如果UML图、编程代码、书面文档不能传递出领域知识,那就不是领域模型。

一个好的领域模型应该包含如下特征:

用统一语言来表达领域中的概念;

涵盖了业务活动和规则等领域知识;

对领域内的知识做了适当的提炼和抽象;

建立了一个迭代演进的过程;

有助于业务人员和技术人员的交流;

所以,我们忘记载体,关注于他如何传递领域知识,并且有助于技术人员和业务人员的交流,那他就可以称为领域模型。

模型设计和模型实现其实是两件事情,就像在公司里面老板做战略取舍,基层做战术落地,在领域模型的设计和实现上应该也分开。

模型是作基本职责的分配,程序是模型的具体表达。

Eric Evans说:将分析、建模、设计、编程工作过度分离对模型驱动设计会产生不良影响。

所以要将分析、设计、实现统一到模型设计中考量。

在分析阶段,业务人员和技术人员在一起工作,建立准确和简洁的分析模型,直观传递不同角色对业务知识的理解。

在设计阶段,基于分析模型对模型中的设计进行改进,考虑职责的合理分配和协作,建立有指导意义的设计模型。

在实现阶段,代码忠实反映模型的设计,反映出模型中的领域和知识。

战略设计环节,识别出业务场景下,系统的限界上下文。

在限界上下文中,提取语义相关和功能相关的用例,作为分析建模的重要输入。

战术设计环节,通过用户故事迭代,逐步对比模型进行细化,引入设计模式,结合TDD开发等进行编码实现。

领域服务应该是一系列活动集合,是领域服务下的关键环节。

在每个关键环节,对于不同用户身份,应该有规则映射处理细节,这部分规则可以有机的、结构化的可视化出来,便于沟通。

领域服务应该和领域挂钩,指导每个关键领域下应该有的活动有哪些。

要想实现这些活动集的复用,就需要明确输入和输出,看得清输入、输出、关键流程才敢去复用。

总结来说,领域、领域服务、领域节点、业务身份的关键规则、为领域服务复用的输入和输出,都是可以被可视化和配置化起来的。

相关新闻: