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.
??????? 任何專注于模型的技術人員必須花時間接觸代碼，而不論他（她）在項目中的首要角色是什么。任何負責修改代碼的人必須學會通過代碼來描述模型。每一個開發人員必須不同程度的被納入到對模型的討論以及和域專家的交流中。那些上述工作之外所涉及的項目人員必須自覺地讓那些接觸代碼的人通過通用語言動態的交換對于模型的意見。