前面我们讲了如何从业务领域获取知识，创建领域模型，那么建立领域模型应当注意什么呢？

建立领域模型应当注意的问题

1．领域模型不是数据模型，也不是软件对象模型

一个创建领域模型的过程中非常容易犯的错误就是，将领域模型当成了数据模型，或者软件对象模型。领域模型，又称为概念模型、领域对象模型或分析对象模型，是“专用于解释业务领域中重要的‘事物’和产品”[RUP]。领域模型专注于现实世界的对象（概念类）而非软件世界的对象。它不包含任何数据库元素、软件类、系统架构以及有职责的软件对象。日后的分析模型、设计模型以及数据模型，将以领域模型作为参考，但很可能与领域模型存在较大差异。因此在建立领域模型的时候，不要与这些模型混淆了。

过去C/S的年代，需求分析往往画的是数据模型。数据模型，也就是我们常说的E-R模型（实体-关系模型），它是基于关系数据库的一种分析模型，其间包含了大量的数据库元素，如主键、外键、数据依赖等等。领域模型不是数据模型，它不应当包含这些内容。

领域模型与软件对象模型同为类图，从而造成领域模型常常与这类模型产生混淆。领域模型是对现实世界的对象的反映，因此领域模型不应包含诸如工厂类、窗口界面、软件架构之类的软件元素，领域模型也不等同于之后用于设计开发的分析模型和设计模型。

领域模型中的概念类通常都只有相关的主要属性，没有任何的方法或函数（有时候概念类连属性都可以省略，仅仅描述它们之间的关系）。

2．领域模型不是一张图，而是一系列图形

我在前面曾经提到过，一张复杂而凌乱的类图常常使人迷惑，领域模型也是一样的。领域模型应当划分成一个又一个的场景，每个场景一张图，进行领域分析。根据实际需要，这个场景可以大也可以小。如果某个模块涉及的概念不多并且关系清晰，我们可以使用一个较大的场景进行描述；如果某个模块涉及的概念纷繁并且关系复杂，我们可以划分成一些更小的场景分别进行描述。领域模型划分的场景不论粗还是细，宗旨便是让读者阅读时清晰明了。

3．草图还是建模工具，是个问题

建立领域模型，使用草图还是建模工具呢，这是个问题。按照过去RUP的思想，建模都应当使用Rational Rose这样的建模工具，一步一步地建立一个又一个的模型，然而敏捷开发彻底打破了这一思想。Robert Martin在他的著作《敏捷软件开发》中强烈建议使用草图进行建模，然后通过扫描草图形成最终的文档。我对此也进行了许多的尝试，我的建议是，建模的初期最好不要使用建模工具。建模的初期，不可避免的是模型的反复修改。如果使用建模工具则意味着每一次的修改都必须进行大量的维护工作，没有草图来得方便快捷。当模型逐渐趋于定型以后，可以尝试使用建模工具进行建模，使模型的建立显得更加正规，也便于日后的阅读和使用。

 

 

对领域模型的深入思考

在建立领域模型中，我们通过与客户的沟通，提取出业务领域的概念类，并归纳出这些概念类之间的相互关系。我们做这些事情为我们的需求分析带来什么益处呢？

1．语言的沟通

在软件项目的需求调研过程中，语言沟通一直是困扰我们的一大难题。业务人员在他们自己的领域中有一套他们自身的语言，运用这套语言，他们相互之间可以灵活自如地沟通；软件技术人员在我们的技术领域有我们的一套语言，运用这套语言，我们也可以轻松愉快地沟通。但是，当业务人员和技术人员坐在一起时，问题就出现了。业务人员和技术人员他们各自说各自的一套语言，各说各的话，相互沟通就存在了巨大地障碍。按照以往的经验，解决这个问题的办法就是，技术人员通过自身的努力去掌握业务语言，用业务语言去沟通；业务人员耐心地去解释业务术语给技术人员听，一步一步地去讲解业务领域的一个个流程。这样的过程是一个艰巨的过程。怎样让这样的过程更加高效呢？也许画几个图，用图形化的展示能更加生动形象，从而提高沟通的效率。

同时，领域模型又是日后的技术人员进行分析设计的基础，因此领域模型所采用的语言必须让技术人员能看得懂。正因为领域模型所起到的重要作用——业务领域与技术实现的沟通介质，领域模型必须采用一种通用语言。同时，领域模型对一些关键的业务术语的解释，以及各个概念类相互关系的描述，也大大降低了沟通的难度。

2．知识的消化

我的一位同事正在设计开发一套财务软件，他告诉我他正在努力学习财务知识，期望把自己打造成一个财务专家，我笑了。如果我们要开发财务软件就要成为财务专家，要开发税务软件就要成为税务专家，要开发企业管理软件就要成为企业管理专家，我们的时间精力不允许我们做的。我们开发一套软件并不一定要成为这个领域的专家，而是通过与专家的沟通，获取与我们要开发的软件相关的，这个领域的知识，这些知识对我们是有用知识。要获取这些有用知识，并不一定成为这个领域的专家才能获取。相反，为了成为这个领域的专家，我们可能不得不获取一些对我们开发软件无用的知识。掌握这些无用的知识，对我们毫无意义而空耗了我们的宝贵时间。现在的问题是，如何准确地获取对我们有用的知识呢？

编写用例模型和领域模型，使我们的精力集中到了我们要开发的软件上来。通过它们，我们把我们的注意力集中到了我们要开发的软件，以及与软件相关的所有流程和概念上了。有了这样一个明确的目标，才能让我们掌握业务领域的知识更加高效快捷。

另一个我们不能忽视的问题就是知识的延续性。当需求分析人员理解并掌握的业务领域的知识以后，其实工作并没有完成，他必须把这些知识传递给那些相关的技术人员。只有技术人员掌握了这些知识以后，才能开发出合格的软件产品。当软件开发结束以后，这个知识还在延续，还要传达给今后的维护人员，甚至再往后的二次开发人员。领域模型的不断积累，就是这种领域知识的不断延续。

3．低表示差异

OOA/D的核心思想就是，软件系统中的所有对象都是有各种职能的、高度内聚的对象，软件功能的实现就是这些对象根据各自的职能相互配合完成的。为了实现这样一个设计思想，低表示差异的概念被提出来了。什么是低表示差异呢？说得更加直白一点儿就是，软件中的对象及其职能，与现实世界中对应的事物及其职能，应保持尽量接近。低表示差异为降低软件设计难度，提高系统可读性，都带来了极大好处。毫无疑问，在需求分析阶段建立领域模型，大大提高了软件设计的低表示差异。

 

 

参考文献：

 

 

中文名：《领域驱动设计——软件核心复杂性的应对之道》

英文名：Domain-Driven Design: Tackling Complexity in the Heart of Software

作者：Eric Evans

 

 

 

中文名：《敏捷软件开发：原则，模式和实践》

英文名：Agile Software Development: Principles, Patterns, and Practices

作者：Robert Martin

 

 

相关文章：

《 谈谈领域模型的那些事儿 之 从业务领域获取知识 》