Hands-On Modeler
人们总是把软件开发比喻成制造业。通过这个比喻可以推断出一个结论：经验丰富的工程师做设计工作，而技能水平较低的劳动力负责组装产品。这种做法使许多项目陷入困境，原因很简单——在软件开发中设计是无处不在的。开发团队中的每个成员都有自己的职责，但是将分析、建模、设计和编程工作完全分离会对Model-Driven Design 产生不良影响。
作者经在一个项目中负责协调不同的应用程序开发团队，帮助开发可以驱动程序设计的领域模型。但是管理层认为建模人员就应该只负责建模工作，编写代码就是在浪费这种技能，于是他们不准作者编写代码或者与程序员讨论细节问题。
开始项目进展得还算顺利。作者和领域专家以及各团队的开发负责人共同工作，消化领域知识并提炼出了一个不错的核心模型。但是该模型却从来没有派上用场，原因有两个。
其一，将模型传递给开发人员的过程中，模型的一些意图并没有像他们说明。模型的整体效果受细节的影响很大，这些细节问题并不时总能在UML图或者一般讨论中遇到的。如果我能做好准备，直接与开发人员共同工作，提供一些参考代码和近距离的技术支持，那么他们也许能够理解模型中的抽象概念并据此进行开发。
第二个原因是模型与程序实现及技术互相影像，而我无法直接获得这种反馈。例如，程序实现过程中发现模型的某部分在我们的技术平台上的工作效率极低，但是经过几个月的时间，我才一点一点获得了关于这个问题的全部信息。也许只需较少的改动就能解决这些问题，但是接个月过去了，改不改已经不重要了。因为开发人员已经自行编写出了可以运行的软件——完全脱离了模型的设计，在那些还在使用模型的地方，也仅仅是把他当做纯粹的数据结构。开发人员不分好坏地把模型全盘否定，但是他们又有什么办法呢？他们再也不愿意冒向人有待在象牙塔里的架构师摆布了。
与其他项目一样，这个项目的初始环境倾向于不让建模人员参与太多的程序实现。对于该项目所使用的大部分技术，作者有着大量的实践经验。在做建模工作之前，作者甚至曾经在同类项目中领导过一个小的开发团队，所以作者对项目开发过程和编程环境分非常熟悉。但是如果不让建模人员参与程序和实现，作者就是有这些经历也无法有效的工作。
如果编写代码的人员认为自己没必要对模型负责，或者不知道如何让模型为应用程序服务，那么这个模型就和程序没有任何关联。如果开发人员没有意识到改变代码就意味着改变模型，那么这个模型就和程序没有任何关联。如果开发人员没有意识到改变代码就意味着改变模型，那么他们对程序的重构不但不会增强模型的作用，反而还会削弱模型的效果。同样，如果建模人员不参与到程序实现的过程中，那么程序实现的约束就没有切身的感受，即使有，也会很快忘记。Model-Driven Design 的两个基本要素（即使模型要支持有效地实现并抽象出关键的领域知识）已经逝去了一个，因此最终模型将变得不再使用。最有一点，如果项目组的分工阻断了设计人员与开发人员之间的协作，是他们无法领悟Model-Dirven Design的奥妙，那么经验丰富的设计人员则不能将自己的知识和技术传递给开发人员。
因此：
任何才与建模的技术人员， 不关在项目中主要职责是什么，都必须花时间了解代码。任何负责修改代码的人员则必须学会用代码来表达模型。每一个开发人员都必须不同程度的参与模型讨论并且与领域专家保持联系。参与不同工作的人都必须有意识的Ubiquitous Language与接触代码的人及时交换关于模型的想法。