Chapter Three. Binding Model and Implementation
If the design, or some central part of it, does not map to the domain model, that model is of little value, and the correctness of the software is suspect. At the same time, complex mappings between models and design functions are difficult to understand and, in practice, impossible to maintain as the design changes. A deadly divide opens between analysis and design so that insight gained in each of those activities does not feed into the other.
        如果一种设计,或者它的一些核心并没有与域模型相关联，那么这个模型就没有价值，并且以此而开发出来的软件的正确性也值得怀疑。同时，模型与功能设计之间复杂的对应关系会变得难于理解，并且当设计变化的时候，它们将很难维护。一种致命的分歧就此在分析与设计之间出现，以至于那些分析设计活动中所获得的见解不能彼此满足。

Design a portion of the software system to reflect the domain model in a very literal way, so that mapping is obvious. Revisit the model and modify it to be implemented more naturally in software, even as you seek to make it reflect deeper insight into the domain. Demand a single model that serves both purposes well, in addition to supporting a robust UBIQUITOUS LANGUAGE.

Draw from the model the terminology used in the design and the basic assignment of responsibilities. The code becomes an expression of the model, so a change to the code may be a change to the model. Its effect must ripple through the rest of the project's activities accordingly.

To tie the implementation slavishly to a model usually requires software development tools and languages that support a modeling paradigm, such as object-oriented programming.

        以书面的形式设计软件系统的一部分，进而与域模型相映射，这样双方的对应关系将会变得明显。重新考虑这些模型并且通过修改让他们在软件当中显得更加自然，甚至是当你在寻求一种方法，来让模型更加深刻的反映问题域的时候也要如此。追求尽可能简单的模型，让它能够满足多方面目的（软件方面和设计方面？），又能够支持足够健全的通用语言。

        从模型中提取那些在存在于设计中，以及存在于（域专家的?）职责所包含的基本工作中的那些术语。代码会因此成为对于模型的一种描述，所以对于代码的更改或许就是源自于对于模型的更改。从而，它们的影响将会波及到项目其他部分的行为。
        要牢固的把实现和模型绑定在一起，通常需要一些软件设计工具以及支持模型范例的语言，例如面向对象程序设计。
       

If the people who write the code do not feel responsible for the model, or don't understand how to make the model work for an application, then the model has nothing to do with the software. If developers don't realize that changing code changes the model, then their refactoring will weaken the model rather than strengthen it. Meanwhile, when a modeler is separated from the implementation process, he or she never acquires, or quickly loses, a feel for the constraints of implementation. The basic constraint of MODEL-DRIVEN DESIGN—that the model supports an effective implementation and abstracts key domain knowledge—is half-gone, and the resulting models will be impractical. Finally, the knowledge and skills of experienced designers won't be transferred to other developers if the division of labor prevents the kind of collaboration that conveys the subtleties of coding a MODEL-DRIVEN DESIGN.
        如果写代码的那些人对于模型没有责任感的话，或者他们并不能懂得如何让模型作用于应用，那么模型对于软件来讲毫无用处。如果开发人员不能够认识到对于代码的修改就是对于模型的修改的话，它们的重构将会使模型变得更糟，而不是让它们更加健壮。同时，当一个从事建模的人与实现过程相隔离的时候，他（她）永远也不会获得，或者说会很快失去对于实现的约束感。模型驱动设计的基本约束即是--模型需要对那些有效的（程序）实现提供支持，并且能够抽象关键的域知识--任缺其一，模型都会变得不切实际。最后，如果项目中的分工阻止了能够微妙的改善模型驱动设计代码编写的那些协作，那么团队中经验丰富的设计人员的知识和技术将不能给的其他设计人员带来提高。

Any technical person contributing to the model must spend some time touching the code, whatever primary role he or she plays on the project. Anyone responsible for changing code must learn to express a model through the code. Every developer must be involved in some level of discussion about the model and have contact with domain experts. Those who contribute in different ways must consciously engage those who touch the code in a dynamic exchange of model ideas through the UBIQUITOUS LANGUAGE.
        任何专注于模型的技术人员必须花时间接触代码，而不论他（她）在项目中的首要角色是什么。任何负责修改代码的人必须学会通过代码来描述模型。每一个开发人员必须不同程度的被纳入到对模型的讨论以及和域专家的交流中。那些上述工作之外所涉及的项目人员必须自觉地让那些接触代码的人通过通用语言动态的交换对于模型的意见。