DDD中的“领域模型”

大家好，欢迎来到小蒋的技术圈。上次跟大家聊到了领域驱动设计，也叫DDD。分享了“美团点评业务系统”他们用DDD到底解决什么样的痛点。领域驱动设计，听这个名字,“领域”肯定在整个体系中占据主导地位。那DDD中提到的“领域模型”是什么？和我们传统软件设计中以及UML中的领域模型有什么关系？今天小蒋准备和大家一起聊聊看。下面我们开始吧。

 

在网上搜索领域模型，有大量的文章。一种是来源于最初的传统软件开发过程，一种来源于领域驱动设计（DDD）。在传统软件开发中，软件设计师通常使用UML语言进行系统建模，里面也在强调领域模型的重要性，这两者很容易混淆。我给大家找到了一些资料，先来看看传统软件开发中，领域模型是什么。

 

 

领域模型是什么？

 

理论派观点：

• Domain Model 是一个商业建模范畴概念，即使一个企业不开发软件，也具备其业务模型；

 

• 所有同行企业，其业务模型必定有非常大的共性和内在的规律性。

 

• 由行业内的各个企业的业务模型再向上抽象出整个行业的业务模型，这个模型称之为“领域模型”。

 

实战派观点：

• 领域模型是有一个分析模型，帮助系统分析人员、用户认识现实业务的工具，描述的是业务中涉及到的实体及其相互之间的关系，它是需求分析的产物，与问题域相关。

 

• 是需求分析人员与用户交流的有力工具，是彼此交流的语言。

 

领域模型作用？

 

理论派

领域模型是一种特殊业务模型，作用是：

• 帮助分析理解复杂业务领域问题。
• 行业内沟通、交流。

 

实战派

领域模型作用：

• 分析如何满足系统功能性需求。
• 指导项目后续的系统设计。

 

业务模型作用：

• 帮助系统需求人员理解客户公司业务，下一阶做需求以业务模型为输入得到系统用例。

 

领域模型与业务模型的区别?

理论派

• 领域模型是一种特殊的业务模型，所以具备业务模型的所有特点，但是比业务模型更抽象、更通用。

 

实战派

• 产出阶段不同

业务模型是在软件开发过程中业务建模阶段产生，领域模型是在分析阶段产生。

 

• 作用不同

业务模型是系统需求人员理解客户公司业务的产物，下一阶段需求将以业务模型输入得到系统需求。

 

领域模型是系统分析人员分析如何满足系统功能性需求的产物。下一阶段软件设计将以领域模型为输入。

 

“实战派”举例说明：

当接到项目，需要做一个酒店预订系统，首先先入业务建模，了解客户公司酒店管理的相关 业务，这就会产出业务模型，此时业务模型里除了酒店预订这个业务环节还包括其他与酒店预订同层次的业务环节。

 

接下来将视线聚焦到酒店预订，改进已有流程得到酒店预订系统需求，也就是系统用例和需求规约。

 

接下来通过分析系统用例和需求规约，分析如何满足酒店管理系统功能性需求，从而得到领域模型。

 

 

 

从上面例子描述上看到，“理论派”和“实战派”的领域模型是两个范畴的东西，一个更关注业务，一个更关注软件实现。若没有分清肯定会引起理解混乱。

 

另一种“领域模型”—领域驱动设计（Domain-Driven Design）

 

还有一种“领域模型”，它出自于埃里克·埃文斯（Eric Evans） 的领域驱动设计，简称DDD，DDD是一套综合系统分析和设计的面向对象建模方法，所以要明确区分传统软件开发中的领域模型和领域驱动设计中的“领域模型“。失血模型、贫血模型、充血模型这些类概念都属于DDD范畴的“领域模型”。

 

两种领域模型的区别

 

本文中“领域模型”都代表领域驱动设计中的领域模型。

 

1. 解决的核心问题不同

正如刚刚前面提到的，领域模型是一个用于分析业务的分析模型，在实际项目中要解决的核心问题：

• 如何满足待开发系统的业务功能需求。

 

而DDD中“领域模型”是综合分析与设计的模型，要解决的核心问题是：

• 保证系统设计能满足项目多变的需求。

 

在传统的软件开发流程中，分析（系统需求分析）和设计（系统设计）被划分为两个阶段，分别对应国家“系统分析师”和“系统设计师”两种职称，这种割裂的结果导致，“系统设计师”要基于“系统分析师“需求分析分析的结果做系统设计，然后才能进行编码，这中间会存在信息上的丢失或失真，并且实际过程中业务需求会变，这个变化可能是外界环境的变化或者对业务有更深的理解引起，就更容易引起系统设计与项目需求脱节。埃里克·埃文斯（Eric Evans）提出的DDD思想就是想解决业务与设计被割裂这样的问题。

 

1. 领域不同

 

领域模型是业务分析模型，分析的是系统功能性需求所反映出的核心业务，软件系统只是实现业务的方式而非业务的一部分（提供IaaS服务的公司除外），不会考虑系统设计IT领域里的问题。

 

而DDD中的“领域模型”是综合分析和设计的模型，涉及到系统设计，需要思考系统的边界，故该模型所分析设计的领域是综合了业务领域和IT领域。

 

以酒店预订系统为例，其业务描述如下：

 

• 所有用户都可以通过酒店订房管理系统查看酒店客房信息
• 用户如需预订需先注册成会员

 

以上涉及两个对象：用户、会员。

 

若做业务分析，第一段描述中的“用户”可能就要考虑，究竟这些“用户”是游客呢，还是企业客户。哪种“用户”是主要客户源，如何针对这些“用户”做针对性的服务，以便更加有力的吸引“用户”预订酒店客房。

 

若要考虑系统设计，那第一段描述中的“用户”可能就会忽略，即不在系统边界范围内。只需要要提供“客房查询”功能即可。

 

1. 使用的阶段和岗位不同

 

领域模型是分析业务的分析模型，在实际项目中主要由系统分析师在分析阶段中使用。

 

DDD的“领域模型”是综合分析、设计的模型，在实际项目中横跨分析和设计两个阶段，岗位需要具备“系统分析师”和“系统设计师”的综合能力。

 

 

为什么要区分，不能混淆？

 

1. 包含的内容不同

 

领域模型主要内容：

 

• 业务实体
• 业务实体之间关系

 

DDD的“领域模型”主要内容：

 

• 业务实体
• 业务实体属性
• 业务实体之间关系
• 服务
• 服务与实体之间的关系

 

1. 总结

 

领域模型分理论派和实战派，理论派属于商业范畴不属于软件开发范畴，软件开发过程不用理会理论派，切忌相互混淆。

 

实战派认为领域模型是一种分析模型，用于分析理解复杂的业务领域问题，具体到软件开发过程中，就是在分析阶段分析如何满足系统功能性需求。

 

同时在软件开发范畴还有来自于DDD的“领域模型”，这是一种综合分析与设计一体的模型，不仅仅注重需求分析与还更关注系统设计、系统需求的衔接，它要求设计出系统与需求要有较好的一致性，所以针对合理的需求变化也更具有良好的扩展性。

 

这样一对比，领域驱动设计中的“领域模型“就好理解的多了，它的领域模型关注的不仅是业务，还更关注怎么把业务和设计如何有机的结合起来。

 

好的，以上就是今天的分享。下次来聊聊传统的领域模型与领域驱动设计中的“领域模型“都是如何设计系统的，他们分别都有什么优缺点。

 

音频下载地址：https://download.csdn.net/download/wei_wei10/12100999

（审核完成后，可下载）