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

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

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

(资料图片仅供参考)

那，应该如何描述领域模型呢？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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