领域模型

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

概念

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

核心元素

业务角色显示了一个人承担的一系列职责。业务实体表示使用或产生的可交付工件、资源和事件。业务​​用例​​​实现显示了协作的业务角色和业务实体如何执行某个工作流程。使用以下几种图来记录业务用例实现： 图显示参与的业务角色和业务实体。活动图，其中泳道显示业务角色的职责，而对象流显示如何在​​工作流程​​中使用业务实体。 序列图描述业务角色和业务主角之间交互的详细情况，并显示如何在业务用例执行过程中访问业务实体。

业务对象模型将结构的概念和行为的概念结合了起来。

领域模型

它是一个纽带工件，用于对业务关系进行清晰的表述，表述方式与软件开发人员的思考方式类似，同时仍保留一些纯粹的业务内容。将我们所知道的有关业务的信息按照对象、属性和职责进行了合并。

它探索业务领域知识的本质，所采用的方式使我们能够从对业务问题的思考转变到对软件应用程序的思考上来。

它是一种确定需求的方法，使需求能够为待建信息系统使用，并得到该系统的支持。

确定业务对象定义、对象间关系、对象名称和对象间关系名称的流程使我们能够以一种能被业务领域专家理解和验证的精确方式来表达业务领域知识。

命名

对每个业务角色和实体进行命名，要求名称能够表示对象的职责。

一个好的名称通常是名词或动词的名词形式， 每个名称都必须是唯一的。避免使用发音或拼写类似的词以及同义词作为名称，可能需要用好几个单词来组成一个明确的、无需额外说明的名称。

对象

当您研究参与业务中不同​​用例​​的业务角色和业务实体时，可能会发现某些对象如此相似，以致于实际上是一个类。即使不同的业务用例没有相同的要求，类是之间也可能相似到足以被视为一个相同现象的程度。如果是这种情况，您应该将相似的类合并在一起。这就产生了一个业务角色或业务实体，它拥有足以满足不同业务用例要求的关系、属性和操作。

因此，多个业务用例可以对同一个类有不同的要求。对于业务角色来说，如果有些雇员有能力担当所描述的一组角色，那么同样还要有一些比较灵活可以胜任多个职位的雇员。这会使您的业务更加灵活   。

模型

在业务对象模型中，业务角色代表雇员将担当的角色，而业务实体则代表雇员将处理的对象。一方面，可以使用业务对象模型来确定业务雇员将如何进行交互，以产生业务主角所期望的结果。另一方面，系统用例模型和设计模型指定了业务的信息系统。

​​业务建模​​和系统建模解决不同的问题，其抽象程度也不一样。所以一般而言，信息系统不应该直接出现在业务模型中。

另一方面，雇员作为业务角色来使用信息系统，实现相互之间的通信、与主角的通信以及对业务实体信息进行访问。所有的链接、关联关系或属性都有某个潜在的信息系统对其进行支持。

这两类建模环境有以下关系：

作为特定业务角色的雇员与信息系统的一个系统主角相对应。如果建立的信息系统使该雇员在业务​​用例​​​中的所有工作都得到一个系统用例的支持，则他最有可能得到最好的支持。 另外，如果业务用例规模大、生存期长或者合并了多个独立领域中的工作，信息系统用例将可以支持业务角色的操作。 雇员工作的对象（建模为业务实体）常在信息系统中得到表现。在信息系统的对象模型中，这些业务实体作为​​实体类​​​出现。业务实体之间的关联关系和聚合关系常常使设计模型中实体类之间产生对应的关联关系和聚合关系。 因此，系统用例访问并操作设计模型中的实体类，这些实体类代表由被支持业务用例访问的业务实体。最后，直接使用​​业务信息系统​​的业务主角也成为信息系统的系统主角。 当确定对支持业务的信息系统的需求时，这些关系十分关键。

主角

有时候，一个业务的雇员与另一个业务的雇员使用其他业务的信息系统进行联系。从建模后业务的角度来看，这个信息系统就是一个业务主角。

示例： 某个软件开发人员努力去理解他所负责的产品中出现的问题。为了了解问题是否源于他所使用的编程工具，他与供应商的万维网服务器联系，并仔细研究编程工具当前版本中已知问题的列表。通过这种方式，业务角色“软件开发人员”与业务角色“提供商的万维网服务器”进行交互。

定位

通常的做法是不在业务对象模型中对信息系统进行明确建模，因为信息系统只是业务角色所使用的工具而已。但当业务的信息系统被客户直接使用时，这种做法就不合适了。如果这个交互是业务服务的主要部分，您可能会出于商业上重要性的考虑而希望在业务对象模型中将其展示出来。电话银行业务就是此类信息系统的一个很好的例子。

从业务建模的观点来看，建议使用以下方法：

将信息系统看做一个和主角交互的完全自动化的业务角色。如果信息系统和任何其他业务角色或业务实体相关，则考虑使用链接或关联关系来说明这种关系。系统可能会向某个业务角色通知其进度，或者使用与某个业务实体相关的信息。 简单地说明业务角色，同时列出代表业务对象模型中信息系统的服务。在信息系统模型中对信息系统和其环境的所有细节和特征进行建模。引入一个命名约定，这样可以容易地在业务角色中确定那些完全自动化的业务角色，例如，一个前缀或后缀，如“自动<业务角色名称>”或“<业务角色名称>（IT 系统）”。您甚至可以使用一个特殊的图标来定义构造型 [3]  。

特征

总的来看，业务角色和业务实体执行业务​​用例​​中描述的所有活动，绝不多一点，也绝不少一点。业务对象模型有效、全面地对组织进行了展示。

实例

举一个简单的例子来说明如何进行领域模型设计。

假如我们要为一个小卖店设计一套​​进销存系统​​​，她为我们提供的业务描述是这样的：每天凌晨从布吉农批市场买苹果、梨、​​葡萄​​、橘子、香蕉、荔枝、核桃等等，反正哪些好卖她就买回来卖。葡萄、荔枝不能长久保留，一般要当天卖出去…。

针对上面这段业务描述，我们怎么进行领域模型设计？我给出以下几个步骤来完成领域模型设计。

总结业务描述中的名词

首先建一个名词表，把涉及到的名词列出来：

序号名词备注；

1. 布吉农批市场

2. 买东西的人是一个隐含的名词，每天凌晨从农批市场拿货

3. 苹果

4. 梨

5. 葡萄

6. 橘子

7. 香蕉

8. 荔枝

9. 核桃

10. 顾客是一个隐含的名词，买回来卖的对象

11. 凌晨、当天时间名词，与实体及角色无关

这个名词列表包括了业务的行为主体：角色，以及业务过程中的操作实体：模型，对我们接下来的​​用例​​描述、领域模型分析、需求分析很有帮助。当然这个名词列表需要经过进一步分析提炼，成为领域模型

确定业务实体

序号名词描述；

1. 布吉农批市场不是本业务的一个实体

2. 买东西的人是本业务的一个角色

3. 苹果是一个实体

4. 梨是一个实体

5. 葡萄是一个实体

6.橘子是一个实体

7. 香蕉是一个实体

8. 荔枝是一个实体

9. 核桃是一个实体

10. 顾客是本业务的一个角色

11. 凌晨、当天时间名词，与实体及角色无关

经过分析，我们得出的实体是苹果、梨、葡萄、橘子、香蕉、荔枝、核桃，这些是不是模型呢？应该说还不是，还要经过进一步分析：在我们分析的业务领域内，它们有没有共性？苹果、梨、葡萄、橘子、香蕉、荔枝属于水果，核桃属于干果，它们都是果品的一个具体实例。而在水果中葡萄和荔枝属于不宜保存水果，通过这样进一步的分析得出如下的领域模型：

果品​​进销存​​领域模型

这个领域模型不但能反映当前的经营实体，同时给我们需求分析人员和系统功能提供了一定的扩展视野：将来会不会经营食品，短期保持水果采取什么利润空间来促销，长期保存的水果会不会因为保存成本而导致利润下降。

关系

认为领域模型它是一个分析模型，帮助系统分析人员、用户认识现实业务的工具，描述的是业务中涉及到的实体及其相互之间的关系，它是需求分析的产物，与问题领域相关。领域模型是需求分析人员与用户交流的有力工具，是需求分析人员与用户共同理解的概念，是彼此之间交流的语言。而数据模型是系统设计、实现的一部分，描述的是对用户需求在数据结构上的实现，仅此而已。当然数据模型中的概念模型设计与领域模型类似，缺乏的是实体之间更广泛的关系描述。

通常大家会考虑数据怎么存放的问题，我的理解是领域模型设计期间不用考虑数据的存放问题，只考虑业务描述中涉及的实体以及实体之间的关系。

实体之间的关系，很多书都讲了，无非是泛化、依赖和关联，关联又分了一般关联、聚合、组合等等，我这里就不列了。

设计步骤

领域模型设计是需求分析的​​关键步骤​​。它帮助用户及需求分析人员建立业务概念，确定用户业务的问题域，系统涉及的业务范围等等。

领域模型设计的步骤为：

1. 从业务描述中提取名词；

2. 从提取出来的名词中总结业务实体，区分名词中的属性、角色、实体、实例，形成问题域中操作实体的集合；

3. 从业务实体集合中抽象业务模型，建立问题域的概念（例如在前面的例子中，我们把容易变质的水果称之为“短期保持水果”，当然也可以是其它说法，只要能跟用户达成共识即可）；

4. 用UML提供的方法和图例进行领域模型设计、确定模型之间的关系 [4]  ；

种类

失血模型

简单来说，就是domain object只有属性的getter/setter方法，没有任何业务逻辑。

贫血模型

简单来说，就是domain ojbect包含了不依赖于持久化的领域逻辑，而那些依赖持久化的领域逻辑被分离到Service层。Service(业务逻辑，事务封装) --> DAO ---> domain object

　　这种模型的优点：

　　1、各层单向依赖，结构清楚，易于实现和维护

　　2、设计简单易行，底层模型非常稳定

　　这种模型的缺点：

　　1、domain object的部分比较紧密依赖的持久化domain logic被分离到Service层，显得不够OO

　　2、Service层过于厚重

充血模型

充血模型和第二种模型差不多，所不同的就是如何划分业务逻辑，即认为，绝大多业务逻辑都应该被放在domain object里面(包括持久化逻辑)，而Service层应该是很薄的一层，仅仅封装事务和少量逻辑，不和DAO层打交道。

　　Service(事务封装) ---> domain object <---> DAO

　　这种模型的优点：

　　1、更加符合OO的原则

　　2、Service层很薄，只充当Facade的角色，不和DAO打交道。

　　这种模型的缺点：

　　1、DAO和domain object形成了双向依赖，复杂的双向依赖会导致很多潜在的问题。

　　2、如何划分Service层逻辑和domain层逻辑是非常含混的，在实际项目中，由于设计和开发人员的水平差异，可能导致整个结构的混乱无序。

　　3、考虑到Service层的事务封装特性，Service层必须对所有的domain object的逻辑提供相应的事务封装方法，其结果就是Service完全重定义一遍所有的domain logic，非常烦琐，而且Service的事务化封装其意义就等于把OO的domain logic转换为过程的Service TransactionScript。该充血模型辛辛苦苦在domain层实现的OO在Service层又变成了过程式，对于Web层程序员的角度来看，和贫血模型没有什么区别了 [5]  。

胀血模型

基于充血模型的第三个缺点，有同学提出，干脆取消Service层，只剩下domain object和DAO两层，在domain object的domain logic上面封装事务。

　　domain object(事务封装，业务逻辑) <---> DAO

　　似乎ruby on rails就是这种模型，他甚至把domain object和DAO都合并了。

　　该模型优点：

　　1、简化了分层

　　2、也算符合OO

　　该模型缺点：

　　1、很多不是domain logic的service逻辑也被强行放入domain object ，引起了domain ojbect模型的不稳定

　　2、domain object暴露给web层过多的信息，可能引起意想不到的副作用。

　　在这四种模型当中，失血模型和胀血模型应该是不被提倡的。而贫血模型和充血模型从技术上来说，都已经是可行的了。但是我个人仍然主张使用贫血模型。其理由：

　　1、参考充血模型第三个缺点，由于暴露给web层程序拿到的还是Service Transaction Script，对于web层程序员来说，底层OO意义丧失了。

　　2、参考充血模型第三个缺点，为了事务封装，Service层要给每个domain logic提供一个过程化封装，这对于编程来说，做了多余的工作，非常烦琐。

　　3、domain object和DAO的双向依赖在做大项目中，考虑到团队成员的水平差异，很容易引入不可预知的潜在bug。

　　4、如何划分domain logic和service logic的标准是不确定的，往往要根据个人经验，有些人就是觉得某个业务他更加贴近domain，也有人认为这个业务是贴近service的。由于划分标准的不确定性，带来的后果就是实际项目中会产生很多这样的争议和纠纷，不同的人会有不同的划分方法，最后就会造成整个项目的逻辑分层混乱。这不像贫血模型中我提出的按照是否依赖持久化进行划分，这种标准是非常确定的，不会引起争议，因此团队开发中，不会产生此类问题。

　　5、贫血模型的domain object确实不够rich，但是我们是做项目，不是做研究，好用就行了，管它是不是那么纯的OO呢？其实我不同意firebody认为的贫血模型在设计模型和实现代码中有很大跨越的说法。一个设计模型到实现的时候，你直接得到两个类：一个实体类，一个控制类就行了，没有什么跨越。