1.2　什么是领域模型

本书在提到领域模型的时候，一般特指DDD的领域模型，也就是Eric Evans在Domain-Driven Design:Tackling Complexity in the Heart of Software一书中阐述的那种领域模型。DDD要求领域模型既能反映对领域的深度认知，又能直接用于指导软件的设计与实现。

我们可以说领域模型是系统化的领域知识。不系统化的知识是难以传授、掌握和应用的。想象一下，一个会计专业的学生如果不去学习《会计基础》课本，直接上岗记账会出现什么样的状况，恐怕会记得一塌糊涂吧？

为了将领域知识系统化，我们需要做领域分析，而分析得到的结果是一个体现我们对领域认知的概念模型。

那么，我们做领域分析的时候，是不是可以只专注于做好业务领域的分析，构建一个只是反映业务知识的分析模型呢？《领域驱动设计精简版》第13页中对这个问题有论述：

一个推荐的设计技术是创建分析模型，它被认为是与代码设计相互分离、通常是由不同的人完成的。分析模型是业务领域分析的结果，此模型不需要考虑软件如何实现。这样的一个模型可用来理解领域，它建立了特定级别的知识，模型在分析层面是正确的。软件实现不是这个阶段要考虑的，因为这会被看作一个导致混乱的因素。这个模型到达开发人员那里后，由他们来做设计的工作。因为这个模型中没有包含设计原则，它可能无法很好地为目标服务。因此开发人员不得不修改它，或者创建分离的设计，在模型和代码之间也不再存在映射关系，最终的结果是分析模型在编码开始后就被抛弃了。

为什么“分析模型在编码开始后就被抛弃”是一个大问题？为什么领域模型与代码之间应该存在映射关系？

是时候重温这句经典名言了：

程序是写来给人读的，只会偶尔让机器执行一下。

——Abelson和Sussman

与建筑不同，软件具有易变性，在软件开发出来之后，可能还需要经常修改。只有反映高层结构的代码才是易于阅读和理解的。我们都知道，开发人员阅读代码的时间远远多于编写代码的时间。Google的工程师每人每天大约只产出100行新代码！

所以，Evans给出了他认为的更好的分析建模——创建软件高层结构——的建议：

一种更好的方法是将领域建模和设计紧密关联起来。模型在构建时就考虑到软件的实现和设计。开发人员应该被加入到建模的过程中。主要的想法是选择一个能够在软件实现中恰当地表达的模型，这样设计过程会很顺畅并且是基于模型的。将代码与其所基于的模型紧密关联，将会使得代码更有意义，并且与模型保持相关。

——《领域驱动设计精简版》，第14页

那么，DDD的领域模型到底是什么？还是听听Eric Evans的“官方”说法吧：

领域模型不是一幅具体的图，它是那幅图想要去传达的那个思想。它也不是一个领域专家头脑中的知识，而是一个经过严格组织并进行选择性抽象的知识。一幅图能够描绘和传达一个模型，同样，经过精心编写的代码和一段英语句子都能达到这个目的。

——《领域驱动设计精简版》，第3页