领域模型的那些事儿：注意什么

领域模型的那些事儿：注意什么2014-08-08 fangang 前面我们讲了如何从业务领域获取知识，创建领域模型，那么建立领域模型应当注意什么呢？

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

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

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

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

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

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

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

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

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

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