背景
UML比较难学，主要是其本身很复杂并且涉及到大量的概念名词。领域模型就是其中之一，网络上搜索到关于领域模型的知识应该是有两种，一种是来源于最初的传统软件开发过程，一种来源于领域驱动设计（DDD），这两者很容易混淆。以下是我对领域模型这个概念的一些理解。
1. 领域模型是什么？
理论派观点：
- Domain Model是一个商业建模范畴概念，即使一个企业不开发软件，也具备其业务模型；
- 所有同行企业，其业务模型必定有非常大的共性和内在的规律性。
- 由行业内的各个企业的业务模型再向上抽象出整个行业的业务模型，这个模型称之为“领域模型”。
实战派观点：
- 领域模型是一个分析模型，帮助系统分析人员、用户认识现实业务的工具，描述的是业务中涉及到的实体及其相互之间的关系，它是需求分析的产物，与问题域相关。
- 是需求分析人员与用户交流的有力工具，是彼此交流的语言。
理论派
领域模型是一种特殊的业务模型，它分析范围是整个行业，抽象出行业里共性和内在规律性的业务，比业务模型更加抽象，它不属于软件开发范畴的概念，与软件开发无关。
实战派
领域模型是一种分析模型，在软件开发过程分析阶段用于分析如何满足系统功能性需求，属于软件开发范畴，在UML中主要使用类图来描述领域模型。
业务模型是业务建模的输出物，业务建模研究的对象是公司或者组织，业务建模属于软件开发过程中的初始阶段。
软件开发过程：业务建模、需求、分析、设计。
在软件开发过程中我们接触到的领域模型属于实战派。
2. 领域模型作用
理论派
领域模型是一种特殊业务模型，作用都是：
- 帮助分析理解复杂业务领域问题。
- 行业内沟通、交流。
实战派
领域模型作用：
- 分析如何满足系统功能性需求。
- 指导项目后续的系统设计。
业务模型作用：
- 帮助系统需求人员理解客户公司业务，下一阶段做需求以业务模型为输入得到系统用例。
3. 领域模型与业务模型的区别
理论派
领域模型是一种特殊的业务模型，所以具备业务模型的所有特点，但是比业务模型更抽象、更通用。
实战派
- 产出阶段不同
业务模型是在软件开发过程中业务建模阶段产生，领域模型是在分析阶段产生。
- 作用不同
业务模型是系统需求人员理解客户公司业务的产物，下一阶段需求将以业务模型为输入得到系统需求。
领域模型是系统分析人员分析如何满足系统功能性需求的产物。下一阶段设计将以领域模型为输入。
“实战派”举例说明：
当接到项目，需要做一个酒店预订系统，首先进行业务建模，了解客户公司酒店管理的相关业务，这就会产出业务模型，此时业务模型里除了酒店预订这个业务环节还包括其他与酒店预订同层次的业务环节。
接下来将视线聚焦到酒店预订，改进已有流程得到酒店预订系统需求，即系统用例和需求规约。
接下来通过分析系统用例和需求规约，分析如何满足酒店管理系统功能性需求，从而得到领域模型。
"理论派"和“实战派”的领域模型是两个范畴的东西，若没有分清肯定会引起理解混乱。
4. 另一种“领域模型” - 领域驱动设计(Domain-Driven Design)
还有一种“领域模型”，它出自于Eric Evans的“Domain-Driven Design”简称DDD，也就是“领域驱动设计”，DDD是一套综合软件系统分析和设计的面向对象建模方法，所以要明确区分这两种领域模型。失血模型、贫血模型、充血模型这类概念都属于DDD范畴的“领域模型”。
4.1 两种领域模型的区别
本文中“领域模型”都代表领域驱动设计中的领域模型。
1. 解决的核心问题不同
正如前文所说的，领域模型是一个用于分析业务的分析模型，在实际项目中要解决的核心问题是：
- 如何满足待开发系统业务功能需求。
而“领域模型”是综合分析与设计的模型，要解决的核心问题是：
- 保证系统设计能满足项目多变的需求。
在传统的软件开发流程中，分析（系统需求分析）和设计（系统设计）被划分为两个阶段，分别对应国家“系统分析师” 和“系统设计师” 两种职称，这种割裂的结果导致，“系统设计师”要基于需求分析的结果做系统设计后才能进行编码，这中间会存在信息上的丢失或失真，并且实际过程中业务需求会变（可能是外界环境的变化或者对业务有更深的理解引起），就更容易引起系统设计与项目需求脱节。Eric Evans提出的DDD思想就是想解决这样问题。
2. 领域不同
领域模型是业务分析模型，分析的是系统功能性需求所出核心域的业务，软件系统只是实现业务的方式而非业务的一部分（提供IaaS服务的公司除外），不会考虑系统设计IT领域里问题。
“领域模型”是综合分析和设计的模型，涉及到系统设计，需要思考系统的边界，故该模型所分析设计的领域是综合了业务领域和IT领域。
以酒店预订系统为列，其业务描述如下
- 所有用户都可通过酒店订房管理系统查看酒店客房信息
- 用户如需预定需先注册成会员
以上涉及到两个对象：用户、会员。
若做业务分析，第一段描述中的“用户”可能就需要考虑，它可能是游客、咨询者的业务含义。
若要考虑系统设计，第一段描述中的“用户”可能就会忽略，即不在系统边界范围内。
3. 使用的阶段和岗位不同
领域模型是分析业务的分析模型，在实际项目中主要由系统分析师在分析阶段中使用。
DDD的“领域模型”是综合分析、设计的模型，在实际项目中横跨分析和设计两个阶段，岗位需要具备“系统分析师”和“系统设计师”的综合能力。
4. 包含的内容不同
领域模型主要内容：
- 业务实体
- 业务实体之间关系
“领域模型”主要内容：
- 业务实体
- 业务实体属性
- 业务实体之间关系
- 服务
- 服务与实体之间的关系
5. 总结
领域模型分理论派和实战派，理论派属于商业范畴不属于软件开发范畴，软件开发过程不用理会理论派，切忌相互混淆。
实战派认为领域模型是一种分析模型，用于分析理解复杂业务领域问题，具体到软件开发过程中就是在分析阶段分析如何满足系统功能性需求。
同时在软件开发范畴还有来自于DDD的“领域模型”，这是一种综合分析与设计一体的模型，注重系统设计与需求分析、系统需求的衔接，设计出系统与需求有较好的一致性，针对合理的需求变化也更具有良好的扩展性。
