[DDD读书笔记] 运用模型①什么是领域模型

翠云山柠檬丸
2,882 阅读7分钟

书籍简介

埃里克·埃文斯（Eric Evans）所著的《领域驱动设计：软件核心复杂性应对之道》这本书，自从2003年出版以来，在世界范围内影响极大。作为DDD的开山之作，纵使已经过去18年，其中的思想至今仍然非常有意义，是我们学习DDD的必经之路。

此书分为4个部分：

第一部分“运用领域模型”提出领域驱动开发的基本目标，这些目标是后面几部分中所讨论的实践的驱动因素。由于软件开发方法有很多，因此第一部分还定义了一些术语，并给出了用领域模型来驱动沟通和设计的总体含义。

第二部分“模型驱动设计的构造块”将面向对象领域建模中的一些核心的最佳实践提炼为一组基本的构造块。这一部分主要是消除模型与实际运行的软件之间的鸿沟。

第三部分“通过重构来加深理解”讨论如何将构造块装配为实用的模型，从而实现其价值。这一部分没有直接讨论深奥的设计原则，而是着重强调一个发现过程。有价值的模型不是立即就会出现的，为了对领域一步一步深入理解，需要反复改进这个模型设计。

第四部分“战略设计”讨论在复杂系统、大型组织以及与外部系统和遗留系统的交互中出现的复杂情况。这一部分探讨了作为一个整体应用于系统的3条原则：上下文、提炼和大型结构。

下面我们带着问题，一起来读读这本书吧。

本书解决什么问题

在Martin Fowler写的序言中，他就直接点明：使软件开发复杂化的根本原因是问题领域本身的复杂性。Eric在前言部分也阐明：

很多因素可能会导致项目偏离轨道，如官僚主义、目标不清、资源缺乏等。但真正决定软件复杂性的是设计方法。

然而很多应用程序最主要的复杂性并不在技术上，而是来自领域本身、用户的活动或业务。当这种领域复杂性在设计中没有得到解决时，基础技术的构思再好也无济于事。

所以本书的希望解决的问题，就是如何用良好的设计方法，来解决由于领域复杂性带来的问题。

本书中的讨论基于以下两个前提：

（1）在大多数软件项目中，主要的焦点应该是领域和领域逻辑；

（2）复杂的领域设计应该基于模型。

作者Eric在前提中就给出了问题的答案，那就是基于模型的设计方法。

什么是领域模型

维基百科给出的解释是：模型是指用一个较为简单的东西来代表另一个东西。而Eric的定义是：

模型是一种简化。它是对现实的解释——把与解决问题密切相关的方面抽象出来，而忽略无关的细节。

简而言之就是抽出重要的，忽略无关的。Eric还对在领域驱动设计中，模型的作用作了如下说明：

(1)模型和设计的核心互相影响。

(2)模型是团队所有成员使用的通用语言的中枢。

(3)模型是浓缩的知识。

模型和代码实现之间有着非常紧密的联系，同时它也是开发人员和领域专家之间沟通所使用的通用语言，是整个团队共同认可的浓缩的领域知识。

如何对待建模工作

既然模型有着如此重要的作用，作为软件开发人员，应该如何去运用模型呢？

Eric指出软件开发人员喜欢提高自己的技能，特别是可以量化的部分，比如掌握一门编程语言，学习一个开发框架，学习一种数据库等等。而对工作领域相关的知识不太关心，例如技术人员自身所处的制造业，餐饮业，金融业等等领域，认为学习领域知识，对提高计算机人才的能力没有用处，更加对领域建模不感兴趣。

我们需要明白软件的核心是什么？并不是各种计算机技术的堆叠，而是像Eric所说的：

软件的核心是其为用户解决领域相关的问题的能力。所有其他特性，不管有多么重要，都要服务于这个基本目的。

开发人员不能把领域知识的学习和领域建模交给其他人，而试图用单纯的技术来解决领域问题。解决软件核心的复杂性问题，需要开发人员直接去面对和解决。Eric同时还苦口婆心的劝说道，掌握建模的技巧可以让软件自身变得井井有条，可以让开发人员的价值倍增！

如何建立领域模型

书中给出了一个形象的比喻：

建模更像是制作电影——出于某种目的而概括地反映现实。

如果是拍电影，谁来做编导呢？换句话说谁来复杂创作？在传统的瀑布方法中，一般存在3种角色，业务专家与分析员和程序员。业务专家与分析员进行讨论，分析员消化理解这些知识后，对其进行抽象并将结果传递给程序员，再由程序员编写软件代码。这里业务专家负责描述现实，分析员负责概括，程序员负责制作，编导似乎是分析员。Eric指出：

由于这种方法完全没有反馈，因此总是失败。分析员全权负责创建模型，但他们创建的模型只是基于业务专家的意见。他们既没有向程序员学习的机会，也得不到早期软件版本的经验。知识只是朝一个方向流动，而且不会累积。

如果程序员只是按照分析员的描述来构建软件，而不去理解其背后的原因，不去学习领域知识，这样开发出来的软件在当时也许可以用，但随着变更不断增加，必将陷入泥潭。单纯由技术人员来建模，缺少领域专家的支持也是不行的。编导应该由整个团队一起负责。

在团队所有成员一起消化理解模型的过程中，他们之间的交互也会发生变化。

团队成员需要在互相学习的过程中建模。开发人员要学习业务原理，领域专家要学习软件项目所需的严谨性。 Eric还引述了Kerievsky的话：

高效率的团队需要有意识地积累知识，并持续学习。

在Eric看来，领域模型和相应的设计就是团队积累的知识。

系列文章

avatar
文章
阅读
粉丝