目录
  1. 1 前言
  2. 2 什么是领域模型
    1. 2.1 定义
    2. 2.2 与其他作者的定义的异同
    3. 2.3 领域模型的特点
  3. 3 为什么要做领域建模
  4. 4 如何进行领域建模
    1. 4.1 用例分析法
    2. 4.2 DDD的方法
    3. 4.3 四色建模法
  5. 5 从领域模型到系统模型
  6. 6 领域模型与系统架构
  7. 7 一些感想
  8. 8 参考资料

1 前言

  最近工作中,我对于模型的设计,尤其是“领域模型”的设计有一些思考和讨论。这篇文章总结了我对领域建模的看法和方法论,也相当于汇总了各位大师对领域建模的不同思想。
  领域建模的目标,是解决复杂业务中软件开发的一系列问题。领域建模也是实现这个目标的一条路径,一种方法论。在实践的过程中可能有一种似曾相识的感觉:虽然没听过这个概念,但是这种做法很有道理而且有可能我们本身就在做。
  需要注意的是,领域建模的方法有多种,甚至关于领域模型本身的定义也有一些模糊之处。不同的方法论和流派思路大体相似,在细节上还有一些区别。不过条条大路通罗马,他们没有对错之分。
  本文更多表现的是我对领域建模的理解,也希望对各位有所启发。

2 什么是领域模型

2.1 定义

  领域模型,在本文中的定义源于《UML和模式应用》[1],这本书对领域建模的概述是最完整、可操作性最强的。

领域模型(domain model)是对领域内的概念类或现实世界中对象的可视化表示。领域模型也成为概念模型、领域对象模型和分析对象模型。

  领域模型是一种概念模型,也叫问题域模型。它表述的是某个领域的现实概念。

2.2 与其他作者的定义的异同

  本文提到的领域模型,基于C Larman在书中的定义。同时与其他作者定义的模型区别如下:

作者 定义 出处 异同
Martin Fowler Conceptual model Analysis Patterns: Reusable Object Models [3] 相同
Martin Fowler Domain Model Patterns of Enterprise Application Architecture [4] 不同。这里的领域模型指的是solution space的领域层的模型对象,也就是本文指的系统模型。其定义需要包括行为和数据的对象模型,即充血模型。
Eric Evans Model Domain-Driven Design –Tackling Complexity in the Heart of Software [5] 不完全相同。这本经典的DDD理论,不再将分析模型和程序设计分离开,而是寻求一种能满足这两方面的单一模型。因此DDD的模型既是领域模型,又是系统模型。同时,通用语言也可以算作领域模型的一部分。
George Fairbanks Domain Model Just Enough Software Architecture [6] 相同
Object Management Group Computation Independent Model (CIM) OMG. MDA Guide Version 1.0.1 相同
Grady Booch Object-oriented analysis Object-oriented Analysis and Design with Applications, 3rd edition [7] 相同。面向对象分析的产出物就是问题域模型。

  其实可以看到,自从面向对象出现以来,出现了很多模型的分析和设计的方法(包括一些需求分析的方法)。其中有一点是共通的:程序设计要从问题域出发,用问题域分析出的模型来指导程序设计。

2.3 领域模型的特点

总结一下,领域模型具有如下的特点:

3 为什么要做领域建模

  首先,建模的重要性在所有工程实践中都已经得到了广泛的认同。建模是一种抽象和分解的方法,它可以将复杂的问题拆解成一个个抽象,代表了特定的一块密集而内聚的信息。[7]
  上世纪80年代开始,人们对于面向对象建模产生了许多思考和方法,其中最流行的就是面向对象分析与设计[8]。面向对象分析,强调的是在问题域发现并描述概念,解决的问题是做正确的事情。面向对象设计,强调的是定义软件对象,解决的问题是正确的做事情
  领域模型就是面向对象分析的主要产物,它表达了对现实问题的描述和抽象。

  不过我们为什么要按照这种流程来进行开发呢?理论上说,如果不做分析和设计,你也可以直接去做代码实现(甚至使用面向过程的编程语言),一样可以完成软件的功能需求。

总结:
  领域建模可以降低软件和现实世界之间的差异,用真实的业务概念划分职责,目的是实现一个可以高效低成本维护的可持续发展的软件系统。
  从领域模型推导到系统实现是一套引导思考的方式,也是一套科学的开发流程。其核心目的在于提供了系统设计的“指导方针”。领域模型必须站在用户需求和业务发展的角度上,既可以用来同客户沟通验证需求,又可以避免模型因实现的考量而带偏(实现成本、遗留系统)。

4 如何进行领域建模

  同样,领域建模的方法也有很多种。下面列出的是一些常见的方法。需要注意,领域建模是需要依赖大量经验和思考的,各种方法起到的都是引导思路的作用:

4.1 用例分析法

  用例分析法是进行领域建模最简单可行的方式。其步骤如下:

下面举个例子,内容来自《Object-Oriented Analysis from Textual Specifications》[9]论文,该文章讲述了如何通过自然语言分析来做面向对象分析(OOA)。

4.2 DDD的方法

  Eric Evans的著作Domain-Driven Design领域驱动设计,简称DDD。DDD是一套软件开发方法论,用来解决复杂的现实问题。
  DDD本身是一套完整、详尽的方法论,从如何需求沟通(构建领域知识),到高层设计(战略建模)、详细设计(战术建模),细致到代码的实现风格都给出了示例。本文无意也无力来详述DDD的所有知识,但是关于如何建模,DDD给出了很多思想可以借鉴。
  需要再次强调的是,DDD的模型本质上是solution space的模型,然而DDD强调模型与实现绑定,因此这里指的“模型”,可以说是领域模型,也可以是系统模型。下面就是DDD建模的一般步骤:

4.3 四色建模法

  四色建模法源于《Java Modeling In Color With UML》[10],它是一种模型的分析和设计方法,通过把所有模型分为四种类型,帮助模型做到清晰、可追溯。

5 从领域模型到系统模型

  提到模型,大多数人第一反应就是一个类或者对象,我这里指的系统模型就是这种概念。
  为了保证程序实现能够遵循领域模型的思想,为了让所有人对领域和职责的认知没有偏差,我强烈建议每个领域模型都要有一个系统模型与之对应,最好能完全一一对应(DDD就是这么做的),他们的命名和属性也尽可能保持一致,使用相同的术语。
  具体到系统模型的设计,就是面向对象设计的范畴了,这里可以使用各种各样的设计模式、GRASP、SOLID去设计和规划,本文就不在此展开。
  需要遵循的宗旨是,领域模型的模型职责、子域边界划分应该作为此处设计的指导原则,在实现中的每个模块不可以突破这些职责约束。

6 领域模型与系统架构

  既然谈到了架构,我们先看看什么是架构,下面是ISO/IEC/IEEE 42010对软件架构的定义[12]:

fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution

可以看到有三个要素,elements,relationships,principles:

  领域模型和系统架构是什么关系呢?领域模型应该作为架构设计的重要输入,通常来说,领域模型的粒度较细,不足以作为软件架构的element或者component来解释,但是进一步抽象,领域模型的子领域划分是很好的模块划分方式,领域划分可以直接应用于架构的模块职责划分上。
  除了领域模型,系统架构还需要考虑其他几个重要因素:

7 一些感想

  一切的方法论,都需要基于一些理想化的假设,但是现实世界的复杂注定了没有一套方法论是万能的、完整的。现实世界中,往往是这样的:

  因此,领域建模的的确确十分依赖经验,并不同于纯粹的技术,更是个人综合能力的一种体现。

8 参考资料

[1] Larman C. Applying UML and patterns[J]. Pearson Schweiz Ag, 2004.
[2] Martin J, Odell J J. Object-Oriented Methods: A Foundation[J]. Object-oriented methods : a foundation, 1998, 222(2):3–11.
[3] Fowler M. Analysis Patterns: Reusable Object Models[M]. DBLP, 1997.
[4] Fowler M. Patterns of enterprise application architecture[M]. 中国电力出版社, 2004.
[5] Evans. Domain-Driven Design: Tacking Complexity In the Heart of Software[M]. 2004.
[6] Fairbanks G, Garlan D. Just Enough Software Architecture: A Risk-Driven Approach[J]. Crc Press, 2010.
[7] Booch G, Maksimchuk R, Engle M, et al. Object-oriented analysis and design with applications, third edition.[M]// Object-oriented analysis and design with applications /. Benjamin/Cummings Pub. Co. 1994:1275-1279.
[8] https://en.wikipedia.org/wiki/Object-oriented_analysis_and_design
[9] Moreno A M. Object-Oriented Analysis from Textual Specifications[C]// of 9 Th International Conference on Software Engineering and Knowledge Engineering. 1997:157.
[10] Coad P, Deluca J, Lefebvre E. Java Modeling in Color with UML[J]. 1999.
[11] 运用四色建模法进行领域分析
[12] Systems and software engineering — Architecture description
[13] 还有很多思想参考自阿里内网的一些文章,不便贴出:)