DDD中的模型

“模型”这个词语在DDD中反复出现，是DDD的核心概念。可是我们从Eric在他的著作(Domain-driven design)中，很难找到关于模型的清晰定义。为了帮助大家更好理解模型的含义，我想从模型同需求的关系、模型在DDD中的作用、模型的开发流程等方面阐述我对模型的认识。

需求不是模型

项目开发中，需求人员会定义需求，输出需求文档（有时甚至包括分析模型)。在其他的开发模式中，开发人员对需求确认后，就依据这个需求启动功能开发了。

但DDD要求模型既要能反应业务，描述业务知识；又要能用于驱动开发，便于编码实现。需求人员给出的需求或者分析模型往往只描述了业务规则，肯定不会考虑开发的需要，因此我们不能把需求直接用作模型。

模型是消化领域知识的结果

需求是建模的输入。需求人员给出的需求，蕴含了领域知识和概念，我们需要通过需求确认活动消化这些知识。

在DDD中，这个确认需求、消化知识的过程就是建模，得到的输出物就是模型。

因此，模型就是我们对领域的理解，就是开发团队对领域知识的表达。

模型驱动开发

得到模型后，DDD要求我们在代码中无偏差地实现模型，也就是所谓模型驱动开发(model-driven-design, MDD)。

MDD除了能够保证模型中的领域知识在开发阶段不出现遗失或者走样；更重要的是，能够让开发人员在编码中发现模型问题，比如：某些概念类很相似，如果它们之间有继承关系可以避免很多重复代码；有很多业务方法的执行路径相同，应该可以通过策略模式或者其他方式提高代码的扩展性；某个业务的实现路径过于复杂，依赖东西太多，很难测试。这些问题在其他的开发模式下，可能只是开发问题，不用告诉需求/业务人员。但是在MDD中，这些问题就是模型问题，它说明模型还不是很合理，需要重构。MDD要求我们牢记一点：模型代码的问题就是模型的问题，修改/重构模型代码就是在修改/重构模型。

我们发现，如果使用MDD，需求和开发不再是上下游的关系，而是建立了一种“依赖倒置"的关系：需求的变化是不受控制的，但是我们可以让变化通过我们需要的方式(即模型)暴露出来。

DDD = domain-driven-model + model-driven-design

从模型的角度看，完整的DDD包括两个阶段，或者说两类活动，首先是模型设计。开发人员和业务人员共同参与模型设计，但起主导作用的是开发人员。接下来是模型实现，开发人员通过编码，应用DDD的模式和建议，在代码层面实现模型。

在项目的迭代开发中，需求不断增加和演进，我们的模型也会随之变化，但是模型的每次迭代，仍然是由上面的两个活动构成的。

模型的表现形式没有规定，可以是任何清晰，便于描述和传播的形式，比如：UML类图和交互图，一些辅助的说明性文字或者解释性的示意图等。

模型的外延

围绕模型，DDD还定义了一些扩展概念。

1, 通用语言 （Ubiquitous Language ）

通用语言是基于模型形成的内部工作语言，用于内部，尤其是开发人员和业务人员之间的问题交流。

实际上，在以往的项目中，即使不采用DDD，团队内部也会自发地形成一套通用语言。不过，DDD要求通用语言的基本元素来自于模型，所有模型中的定义都要包含在通用语言中。

2, 战略模型(strategic model )和战术模型(tactical model)

战略模型用于描述大型系统中的BC构成以及它们之间的关系。

战术模型用于描述BC内部的领域知识。

模型的成本

采用DDD开发确实有成本，但是这个成本的增加并不体现在编码上，和其他开发模式相比，DDD并没有要编写额外代码，也没有在技术上有特别要求和挑战。增加的成本源自于DDD对模型设计活动的要求。

在其他的开发模式中，模型设计活动通常是单向的，由需求或者开发完成，不涉及到两个团队的交流和讨论。而在DDD中，模型设计需要开发人员和业务人员共同参与，为了能达成一致，需要付出沟通成本。而开发人员要主导设计过程，需要学习DDD，有一定的学习成本。

当然，成本的回报就是得到一个统一的模型。