DDD 领域驱动设计 第3章 绑定模型和实现

3.1 模式： Model-Driven Design

严格按照基础模型来编写代码，能够使代码更好地表达设计含义，并且使模型与实际的系统 相契合。

     如果整个程序设计或者其核心部分没有与领域模型相对应，那么这个模型就是没有价值的，  软件的正确性也值得怀疑。同时，模型和设计功能之间过于复杂的对应关系也是难于理解的，在 实际项目中，当设计改变时也无法维护这种关系。若分析与和设计之间产生严重分歧，那么在分  析和设计活动中所获得的知识就无法彼此共享。

       MODEL-DRIVEN DESIGN(模型驱动设计)不再将分析模型和程序设计分离开，而是寻求一种 能够满足这两方面需求的单一模型。不考虑纯粹的技术问题，程序设计中的每个对象都反映了模型中所描述的相应概念。这就要求我们以更高的标准来选择模型，因为它必须同时满足两种完全不同的目标。

因此:

      软件系统各个部分的设计应该忠实地反映领域模型，以便体现出这二者之间的明确对应关系。我们应该反复检查并修改模型，以便软件可以更加自然地实现模型，即使想让模型反映出更 深层次的领域概念时也应如此。我们需要的模型不但应该满足这两种需求，还应该能够支持健壮 的UBIQUITOUS LANGUAGE(通用语言)。

      从模型中获取用于程序设计和基本职责分配的术语。让程序代码成为模型的表达，代码的改 变可能会是模型的改变。而其影响势必要波及接下来相应的项目活动。

完全依赖模型的实现通常需要支持建模范式的软件开发工具和语言，比如面向对象的编程。

3.2 建模范式和工具支持

     像C这样的语言并不适用于MODEL-DRIVEN DESIGN，因为没有适用于纯粹过程语言的建模范式

     面向对象设计是目前大多数项目所使用的建模范式，也是本书中使用的主要方法

    程序应该有一个交互式的用户界面，可以列出所有总线，让用户逐个指定规则;或者可以向 后兼容，从规则文件中读取规则。采用外观(façade)模式可以更容易地访问这些接口，如下代 码是对应于上面测试的实现代码:

3.3 揭示主旨:为什么模型对用户至关重要

        MODEL-DRIVEN DESIGN要求只使用一个模型(在任何一个上下文中都是如此，第14章会讨论 这一点)。大部分的设计建议和例子都只针对将分析模型和设计模型分离的问题，但是这里的问 题涉及了另外一对不同的模型:用户模型和设计/实现模型。

       如果程序设计基于一个能够反映出用户和领域专家所关心的基本问题的模型，那么与其他设计方式相比，这种设计可以将其主旨更明确地展示给用户。让用户了解模型，将使他们有更多机 会挖掘软件的潜能，也能使软件的行为合乎情理、前后一致。

3.4 模式:HANDS-ON MODELER

       如果编写代码的人员认为自己没必要对模型负责，或者不知道如何让模型为应用程序服务， 那么这个模型就和程序没有任何关联。如果开发人员没有意识到改变代码就意味着改变模型，那 么他们对程序的重构不但不会增强模型的作用，反而还会削弱它的效果。同样，如果建模人员不 参与到程序实现的过程中，那么对程序实现的约束就没有切身的感受，即使有，也会很快忘记。 MODEL-DRIVEN DESIGN的两个基本要素(即模型要支持有效的实现并抽象出关键的领域知识)已 经失去了一个，最终模型将变得不再实用。最后一点，如果分工阻断了设计人员与开发人员之间 的协作，使他们无法转达实现MODEL-DRIVEN DESIGN的种种细节，那么经验丰富的设计人员则不 能将自己的知识和技术传递给开发人员。

     任何参与建模的技术人员，不管在项目中的主要职责是什么，都必须花时间了解代码。任何 负责修改代码的人员则必须学会用代码来表达模型。每一个开发人员都必须不同程度地参与模型 讨论并且与领域专家保持联系。参与不同工作的人都必须有意识地通过UBIQUITOUS LANGUAGE 与接触代码的人及时交换关于模型的想法。