【架构设计】领域模型(概念模型) 、逻辑模型、物理模型、贫血模型、充血模型概念总结【待读与标记】

本文选自：

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

http://blog.csdn.net/zsy_gemini/article/details/9060105

http://wuaner.iteye.com/blog/856450

背景

关于领域模型的知识应该是有两种，一种是来源于最初的传统软件开发过程，一种来源于领域驱动设计（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中完成。

领域模型 

领域模型(domain model)，也称为概念模型、领域对象模型、分析对象模型，我们在对项目进行分析的时候，往往会创建相应的领域模型。 

引用

Java开发三件宝： 
Domain Model   领域模型（如DRP的分销领域） 将现实世界中的东西抽象成模型，通过UML建模等 
Pattern   模式 分分析模式、设计模式。最重要的是知道模式的应用场景，即某一模式所对应的问题所在 
Framework   框架 如Struts、Spring、Hibernate

领域模型（Domain Model）是一个商业建模范畴的概念，他和软件开发并无一丝一毫的关系，即使一个企业他不开发软件，他也具备他的业务模型，所有的同行业的企业他们的业务模型必定有非常大的共性和内在的规律性，由这个行业内的各个企业的业务模型再向上抽象出来整个行业的业务模型，这个东西即“领域模型”。 
--- http://www.iteye.com/topic/11608 

领域模型学习(01)：领域模型简介： 
http://blog.csdn.net/t673afa/archive/2010/05/08/5569413.aspx

引用

领域模型设计的步骤为： 
　　 1. 从业务描述中提取名词； 
　　2. 从提取出来的名词中总结业务实体，区分名词中的属性、角色、实体、实例，形成问题域中操作实体的集合； 
　　3. 从业务实体集合中抽象业务模型，建立问题域的概念（例如在前面的例子中，我们把容易变质的水果称之为“短期保持水果”，当然也可以是其它说法，只要能跟用户达成共识即可）； 
　　4. 用UML提供的方法和图例进行领域模型设计、确定模型之间的关系；

别在领域模型迷失了自己 
http://www.cnblogs.com/tsoukw/archive/2007/09/28/908983.html

引用

领域模型就是对领域内的概念类和现实世界中对象的可视化表示【Mo95,Fowler96】。 针对UP来说领域模型就是业务对象模型

UML小结以及基于领域模型的系统设计初步 
http://www.cnblogs.com/Leo_wl/archive/2010/07/21/1781927.html 

如何进行领域模型设计 
http://blog.csdn.net/chuan122345/archive/2010/01/13/5187302.aspx

引用

一 领域模型的概念 
1.领域模型是对领域内的概念类或现实世界的对象的一种抽象的可视化表示。又称为概念模型，分析模型，它主要关注问题域本身，挖掘问题域中核心的领域概念，并建立领域概念之间的关系。 
2.领域模型之间的关系一般为泛化，依赖和关联，而关联又分为一般关联，聚合和组合。 
3.在进行需求分析时，领域模型来自于业务描述中的名词以及对名词的抽象。当然描述业务的名词不都是模型，有可能是模型的一个属性，也有可能是角色、或者是跟业务无关紧要描述。 
二 领域模型设计的步骤如下： 
1.从用户的业务需求描述中，提取出所有的名词，一般时间名词和地点名词可以除外。 
2.分析所有的名词，从中提取出业务实体，区分名词中的属性，角色，实体，实例，形成操作实体集合。 
3.从业务实体集合中抽象领域模型。 
4.用UML提供的方法和图例进行领域模型设计，确定模型之间的关系。 
三 领域模型的作用 
领域模型描述的是业务中涉及到的业务实体以及相互之间的关系。因此它可以帮助需求分析人员和用户（或用户代表）认识实际业务，从而成为需求分析人员和用户之间交流的重要工具，是他们共同理解的概念，是彼此交流的语言。 
四 数据模型的区别 
数据模型是系统设计，以及实现的一部分，描述的是对用户需求在技术上的实现方法。用户不需要关心系统的数据模型，但是必须关注领域模型，因为领域模型反映的是问题域的相关业务概念以及其关系，领域模型是用户业务描述的高度抽象，来源于业务需求的描述，同时又可以帮助用户和需求分析人员更好的理解业务需求。

领域模型驱动应用心得 
http://blog.csdn.net/HuDon/archive/2009/03/30/4036904.aspx 

概念模型设计： 
http://blog.csdn.net/soltex/archive/2010/05/04/5554821.aspx

引用

可以看出 ， 进行概念模型（领域模型）设计时应当遵循先局部，后整体的设计思路。

概念模型，逻辑模型，物理模型： 
http://www.cnblogs.com/emanlee/archive/2010/12/16/1907656.html

引用

         概念模型就是在了解了用户的需求，用户的业务领域工作情况以后，经过分析和总结，提炼出来的用以描述用户业务需求的一些概念的东西。如销售业务中的“客户”和“定单”，还有就是“商品”，“业务员”。  用USE   CASE来描述就是：“业务员”与“客户”就购买“商品”之事签定下“定单”。 
         逻辑模型就是要将概念模型具体化。要实现概念模型所描述的东西，需要那些具体的功能和处理那些具体的信息。这就到了需求分析的细化阶段。还以销售业务为例：“客户”信息基本上要包括：单位名称，联系人，联系电话，地址等属性；“商品”信息基本上要包括：名称，类型，规格，单价等属性；“定单”信息基本上要包括：日期和时间属性。并且“定单”要与“客户”，“业务员”和“商品”明细关联。 
        系统需要建立几个数据表：业务员信息表，客户信息表，商品信息表，定单表。 
        系统要包括几个功能：业务员信息维护，客户信息维护，商品信息维护，建立销售定单 。 
        以上这些均属于建立逻辑模型，这些说明只表明系统要实现什么，但怎样实现，用什么工具实现还没有讲，后者属于物理模型范围。 
         物理模型就是针对上述逻辑模型所说的内容，在具体的物理介质上实现出来。如：数据库使用SQL Server 2000，这样就可以编写具体的SQL脚本在数据库服务器上将数据库建立起来。其中包括业务员信息表，客户信息表，商品信息表，定单表。客户端使用VS开发工具，那么在工作站上用VS建立起功能菜单，包括：业务员信息维护，客户信息维护，商品信息维护，建立销售定单等功能，并用工具将每一个功能编码实现。 
        这三个过程，就是实现一个软件系统的三个关键的步骤，是一个从抽象到具体的一个不断细化完善的分析，设计和开发的过程。

浅谈领域模型驱动中表的设计方法： 
http://www.uml.org.cn/mxdx/201001151.asp