领域驱动设计可以理解为：严格按照模型来编写代码，能够使代码更好地表达设计含义，并且使模型与实际的系统相契合。
许多复杂项目确实在尝试使用某种形式的领域模型，但是并没有把代码的编写与模型紧密联系起来。这些项目所设计的模型，在项目初期还可能用来做一些探索工作，但是随着项目的进展，这些模型与项目渐行渐远，甚至还会起误导作用。所有在模型上花费的精力都无法保证程序设计的正确性，因为模型和设计是不同的。
软件系统各个部分的设计和编码应该忠实地反映领域模型，以便体现出这二者之间的明确对应关系。我们应该反复检查并修改模型，以便软件可以更加自然地实现模型，即使想让模型反映出更深层次的领域概念时也应如此。我们需要的模型不但应该满足这两种需求，还应该能够支持健壮 的UBIQUITOUS LANGUAGE(通用语言)。
如果编写代码的人员认为自己没必要对模型负责，或者不知道如何让模型为应用程序服务， 那么这个模型就和程序没有任何关联。如果开发人员没有意识到改变代码就意味着改变模型，那么他们对程序的重构不但不会增强模型的作用，反而还会削弱它的效果。同样，如果建模人员不参与到程序实现的过程中，那么对程序实现的约束就没有切身的感受，即使有，也会很快忘记。 MODEL-DRIVEN DESIGN的两个基本要素(即模型要支持有效的实现并抽象出关键的领域知识)已经失去了一个，最终模型将变得不再实用。最后一点，如果分工阻断了设计人员与开发人员之间的协作，使他们无法转达实现MODEL-DRIVEN DESIGN的种种细节，那么经验丰富的设计人员则不能将自己的知识和技术传递给开发人员。
因此:
任何参与建模的技术人员，不管在项目中的主要职责是什么，都必须花时间了解代码。任何负责修改代码的人员则必须学会用代码来表达模型。每一个开发人员都必须不同程度地参与模型 讨论并且与领域专家保持联系。参与不同工作的人都必须有意识地通过UBIQUITOUS LANGUAGE 与接触代码的人及时交换关于模型的想法。
