1、有效建模的要素
- 模型和实现的绑定
- 获得了一种基于模型的语言
- 开发一个蕴含丰富知识的模型
- 提炼模型
2、知识消化
在传统的瀑布方法中，业余专家与分析员进行讨论，分析员消化理解这些知识后，对其进行抽象并将结果传递给程序员，再由程序员编写软件代码。由于这种方法完全没有反馈，因此总是失败。分析员全权负责创建模型，但他们创建的模型只是基于业务专家的意见。他们既没有向程序员学习的机会，也得不到早起软件版本的经验。知识只是朝一个方向流动，而且不会形成积累
有些项目使用了迭代过程，但由于没有对知识进行抽象而无法建立起知识体系。开发人员听专家们描述某项所需的特性，然后开始构建它。他们将结果展示给专家，并询问接下来做什么，如果程序员愿意进行重构，则能保持软件足够整洁，以便继续扩展它；但如果程序员对领域不感兴趣，则他们只会学习程序应该执行的功能，而不会学习它背后的原理。虽然这样也能开发出有用的软件，但项目永远也不会从原有特性中自然地扩展出强大的新特性。
好的程序员会自然而然地抽象并开发出一个可以完成更多工作的模型。但如果在建模时只是技术人员在唱独角戏，而没有领域专家的协作，那么得到的概念将是很幼稚的。使用这些肤浅知识开发出来的软件只会做基本工作，而不会充分反映出领域专家的思考方式。
3、持续学习
高效率的团队需要有意识地积累知识，并持续学习。对开发人员来说，这意味着既要完善技术知识，也要培养一般的领域建模技巧。但这也包括认真学习他们正在从事的特定领域的知识。
善于自学的团队是团队的中坚力量，那些涉及最关键领域的开发任务要靠他们来攻克。这个核心团队头脑中积累的知识使他们成为更高效的知识消化者。
4、知识丰富的知识
当我们的建模不再局限于寻找实体和值对象时我们次啊能充分吸取知识，因为业务规则之间可能会存在不一致。领域专家在反复研究所有规则、解决规则之间的矛盾以及修改规则使其符合常识等一系列工作中，往往不会意识到他们的思考过程有多么复杂。软件是无法完成这一工作的，正是通过与软件专家紧密协作来消化知识的过程才使得规则得以澄清和充实，并消除规则之间的矛盾以及删除一些无用规则。
5、深层模型
有用的模型很少停留在表面层次上。随着对领域和应用程序需求的理解逐步加深，我们往往会丢掉那些最初看起来很重要的表面元素，或者切换它们的角度。这时，一些在开始时不可能发现的巧妙抽象就会渐渐浮出水面，而它们恰恰切中问题的要害。