大家好，又见面了，我是你们的朋友全栈君。

本文选自：

http://www.jianshu.com/p/fe45506ea358

背景

关于领域模型的知识应该是有两种，一种是来源于最初的传统软件开发过程，一种来源于领域驱动设计（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的“领域模型”，这是一种综合分析与设计一体的模型，注重系统设计与需求分析、系统需求的衔接，设计出系统与需求有较好的一致性，针对合理的需求变化也更具有良好的扩展性。

具体领域模型 

领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。

业务对象模型（也叫领域模型 domain model）是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务用例。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象（“业务类和对象”）之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。

贫血模型是指领域对象里只有get和set方法（POJO），所有的业务逻辑都不包含在内而是放在Business Logic层。

优点是系统的层次结构清楚，各层之间单向依赖，Client->（Business Facade）->Business Logic->Data Access Object。可见，领域对象几乎只作传输介质之用，不会影响到层次的划分。

该模型的缺点是不够面向对象，领域对象只是作为保存状态或者传递状态使用，它是没有生命的，只有数据没有行为的对象不是真正的对象，在Business Logic里面处理所有的业务逻辑，对于细粒度的逻辑处理，通过增加一层Facade达到门面包装的效果。

在使用spring的时候，通常暗示着你使用了贫血模型，我们把Domain类用来单纯地存储数据，Spring管不着这些类的注入和管理，Spring关心的逻辑层（比如单例的被池化了的Business Logic层）可以被设计成singleton的bean。

假使我们这里逆天而行，硬要在Domain类中提供业务逻辑方法，那么我们在使用Spring构造这样的数据bean的时候就遇到许多麻烦，比如：bean之间的引用，可能引起大范围的bean之间的嵌套构造器的调用。

贫血模型实施的最大难度在于如何梳理好Business Logic层内部的划分关系，由于该层会比较庞大，边界不易控制，内部的各个模块之间的依赖关系不易管理，可以考虑这样这样的实现思路：

（1）铺设扁平的原子业务逻辑层，即简单的CRUD操作（含批量数据操作）；

（2）特定业务清晰的逻辑通过Facade层来组装原子操作实现。

（3）给业务逻辑层实施模块划分，保持模块之间的松耦合的关系。

举例说明：

原子业务逻辑层（Service）提供了用户模型的条件查询方法：

List<User> queryUser(Condition con)

Facade层则提供了一种特定的业务场景的分子接口，满足18岁的中国公民，内部实现调用的正是上述的原子接口：

List<User> queryAdultChinese()

Facade、Service层纵向划分为几个大的领域包：用户、内容和产品。

充血模型层次结构和上面的差不多，不过大多业务逻辑和持久化放在Domain Object里面，Business Logic只是简单封装部分业务逻辑以及控制事务、权限等，这样层次结构就变成Client->（Business Facade）->Business Logic->Domain Object->Data Access Object。

它的优点是面向对象，Business Logic符合单一职责，不像在贫血模型里面那样包含所有的业务逻辑太过沉重。

缺点是如何划分业务逻辑，什么样的逻辑应该放在Domain Object中，什么样的业务逻辑应该放在Business Logic中，这是很含糊的。即使划分好了业务逻辑，由于分散在Business Logic和Domain Object层中，不能更好的分模块开发。熟悉业务逻辑的开发人员需要渗透到Domain Logic中去，而在Domian Logic又包含了持久化，对于开发者来说这十分混乱。  其次，如果Business Logic要控制事务并且为上层提供一个统一的服务调用入口点，它就必须把在Domain Logic里实现的业务逻辑全部重新包装一遍，完全属于重复劳动。

使用RoR开发时， 每一个领域模型对象都可以具备自己的基础业务方法，通常满足充血模型的特征。充血模型更加适合较复杂业务逻辑的设计开发。

充血模型的层次和模块的划分是一门学问，对开发人员要求亦较高，可以考虑定义这样的一些规则：

（1）事务控制不要放在领域模型的对象中实现，可以放在facade中完成。

（2）领域模型对象中只保留该模型驱动的一般方法，对于业务特征明显的特异场景方法调用放在facade中完成。