很多项目设计之初只考虑到模型如何设计，没有将模型如何实现、数据关系如何存储这些实现考虑在内，往往设计“很完美”的模型交给开发人员却无法落地。

虽然项目初期设计了领域模型，但是模型没有与实现绑定，不能帮助开发可运行的软件，这种纸上谈兵的模型是没有意义的。

模式：MODEL-DRIVEN DESIGN

有些项目设计之初也使用了模型，但这些模型没有考虑到软件的实现，是完全脱离程序设计的分析模型。分析模型仅仅是理解工具，分析中也有一些知识消化的过程，但编码后，程序设计人员不得不重新进行抽象，这会导致领域知识丢失。

模型驱动设计（Model- Driven Design）不再将分析模型和程序设计分离开，而是寻找一种同时满足两方面需求的单一模型。

软件系统的各个部分设计应该忠实地反映领域模型，以明确二者的对应关系。同时也要反复检查和修改模型，以便软件可以更加自然地实现模型。模型不光要满足这两方面的需求，还应该能支持通用语言（UBIQUITOUS LANGUAGE）。

软件开发是一个不断精化模型、设计和代码过程。

为什么模型对用户至关重要?

理论上我们可以展示给用户任意一种系统视图，而不管底层如何实现。但实际上系统上下结构的不匹配轻则导致误解，重则产生bug。

以IE浏览器收藏夹功能为例，IE浏览器用户会认为收藏夹是存储网站名称的列表，网站名称在不同的会话中是保持不变的。但是系统实现却将收藏夹中的书签当作一个包含URL的文件，并将文件名称存储在收藏夹列表中。这样做的问题是，如果网页标题含有Windows系统文件名不能接受的非法字符，就会出 现错误。假如用户想要收藏某页面并将其命名为:“Laziness: The Secret to Happiness”(懒惰:幸 福的秘密)，就会弹出一个错误信息:“文件名不能包含下列任何字符:\ / : * ? " < > |。用户会奇怪文件名是指什么。另一方面，如果网页标题已经包含非法字符，IE浏览器则会悄悄地把字符删 除。这种数据丢失在这种情况下也许危害不大，但绝不是用户所期望的。在大多数应用中，程序悄悄地修改数据是不能接受的。

如果网站收藏夹实际上只是快捷方式文件的集合，那么应该将这一事实告诉用户，还应该删除之前那个起 误导作用的模型。这样不但能使收藏夹的功能更加清晰，用户还可以利用自己所知道的文件系统的知识来对网站收藏夹进行操作。比如，用户可以用资源管理器来重新组织已收藏的文件，而不 是用浏览器内臵的拙劣工具。而电脑高手还能够灵活地在文件系统的任何位臵存储网页快捷方式。仅仅通过删除起误导作用的多余模型就可以让应用程序的功能更加强大且清晰。

模式：HANDS-ON MODELER

人们经常说技术水平较高的架构师负责设计，技术水平相对低的开发人员负责实现代码，这是错误的，因为软件开发就是设计。虽然团队内每个成员都有各自的职责，但是将分析、设计、建模、开发过度分离不利于领域驱动开发。

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

HANDS-ON MODELER(亲身实践的建模者)并不意味着团队成员不能有自己的专业角色。任何参与建模的技术人员，不管在项目中的主要职责是什么，都必须花时间了解代码。任何负责修改代码的人员则必须学会用代码来表达模型。每一个开发人员都必须不同程度地参与模型 讨论并且与领域专家保持联系。参与不同工作的人都必须有意识地通过UBIQUITOUS LANGUAGE与接触代码的人及时交换关于模型的想法。