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类图和交互图，一些辅助的说明性文字或者解释性的示意图等。