领域驱动设计-软件核心复杂性应对之道：第三章
三、绑定模型和实现
模型种类繁多，目的各有不同，即使是那些仅用于软件开发项目的模型也是如此。领域驱动设计要求模型不仅能够指导早期的分析工作，还应该成为设计的基础。这种设计方法对于代码的编写有着重要的暗示作用。不太明显的一点就是：领域驱动设计要求一种不同的建模方法.....
3.1 模式：model-driven design
严格按照基础模型来编写代码，能够使代码更好地表达设计含义，并且使模型更符合设计。
另一方面，许多复杂的项目确实在尝试使用一些领域模型，但是并没有把代码的编写与模型紧密联系起来。这些项目所设计的模型，在项目初期还可能用来做一些探索工作，但是随着项目的进展，这些模型与项目渐行渐远，甚至还会起到误导作用。所有在模型上花费的经历都无法保证程序设计的正确性，因为模型和设计是不同的。
模型和程序设计的联系可能在很多情况下被破坏，但是二者的这种分离往往是有意而为之的。很多设计方法都提倡使用完全脱离于程序设计的分析模型，之所以称为分析模型，是因为它是对业务领域进行分析的效果，它在组织业务领域中的概念时，完全不去考虑自己在软件系统中将会起到的作用。分析模型仅仅是理解工具，在创建分析模型时并没有考虑程序设计的问题，因此分析模型很有可能无法满足程序设计的需求。
在这种分析中会有一些知识校花的过程，但是在编码开始后大部分的领域只是被丢弃，开发人员不得不重新对设计进行抽象，这样就不能保证新的程序设计中还能保留或者重现分析人员所获得的并且嵌入在模型中的领域知识。
纯粹的分析模型甚至无法实现理解领域这一主要目的，因为在程序设计和实现中总是会发现一些关键的知识点，而细节问题则会出人意料地层出不穷。前期模型可能会忽略一些重要的问题，却深入研究另一些不相关的问题，而且它对于其它问题的描述也可能对应用程序没有任何帮助。最后的结果就是，在编码工作开始后纯粹的分析模型被抛弃，大部分的模型都需要重新设计。即便是重新设计，如果开发人员认为分析与程序开发毫不相关，那么建模过程就不会那么规范。而如果项目经理也这么认为，那么开发团队可能没有足够的机会与领域专家进行交流。
如果整个程序设计或者其核心部分没有与领域模型相对应，那么这个模型就是没有价值的，软件的正确性也值得怀疑。同时，模型和设计功能之间太过复杂的对应关系也是难于理解的，在实际项目中改变设计时也无法维护这种关系。分析和设计工作全无关联，导致在这两个过程中所获得的知识无法彼此共享。
分析工作一定要抓住领域内的基础概念，并且用易于理解和易于表达的方式描述出来。设计工作则需要指定一套可以由项目中使用的编程工具创建的组件，使项目可以在目标部署环境中高效运行，并且能够正确解决应用程序所遇到的问题。
model-driven-design(模型驱动设计)不再将分析模型和程序设计分离开，而是寻求一种能够满足这方面需求的单一模型。不考虑纯粹的技术问题，程序设计中的每个对象都反映了模型中所描述的相应概念。这要求我们以更高的标准来选择模型，因为它必须同时实现两种完全不同的目标。
软件系统各个部分的设计应该忠实地反映领域模型，以便体现出这二者之间的明确对应关系。我们应该重复检查并检测模型，在软件中更加自然地实现模型，即使想让它反映出更深层次的领域概念也应如此。我们需要的模型不但应该满足这两种需求，还应该能够支持健壮的通用语言。
从模型中获取用于程序设计和基本任务分配的术语。程序代码就是模型的表达，修改代码可能就是改变模型。而模型的改变势必会影响到接下来的相应的项目活动。
完全依赖模型的实现通常需要支持建模范式的软件开发工具和语言，比如面向对象的编程
建立一个业务专家和开发人员都认可的领域模型，不断更新模型，再用代码表达这个模型。凡是修改、增加、删除都需要在模型上进行验证可行性，再开发
有时，不同的子系统会有不同的模型，但此在从需求分析到代码编写的整个开发过程中，软件系统的每一部分只能对应一个模型
单一模型能够减少出错的概率，因为程序设计直接来源于经过仔细考虑而创建的模型。程序设计，甚至是代码本身，都与模型密不可分。
3.2 建模范式和工具支持
为了使model-driven design发挥作用，一定要在可控范围内严格保证模型与设计之间的一致性。要实现这种严格的一致性，必须要运用由软件工具支持的建模范式，它可以直接模拟模型中的概念。
3.3 揭示主旨：为什么模型对用户至关重要
从理论上讲，也许你可以向用户展示任何一种系统视图，而不管底层如何实现。但实际上，系统上下层结构的不匹配轻则导致功能混乱，重则产生bug
用户模型和设计/实现模型
3.4 模式：hands-on modeler
人们总是把软件开发比喻成制造业。通过这个比喻可以推断出一个结论：经验丰富的工程师做设计工作，而技能水平较低的劳动力负责组装产品。这种做法使许多项目陷入困境，原因很简单-在软件开发中设计是无处不在的。开发团队中的每个成员都有自己的职责，但是将分析、建模、设计和编程工作完全分离会对model-driven design产生不良影响。
hands-on modeler（建模人员参与程序开发）并不意味着团队成员不能有自己的专业角色
任何参与建模的技术人员，不管在项目中的主要职责是什么，都必须花时间了解代码。任何负责修改代码的人员则必须学会用代码来表达模型。每一个开发人员都必须不同程度地参与模型讨论并且与领域专家保持联系。参与不同工作的人都必须有意识地通过通用语言与接触代码的人及时交换关于模型的想法
