每个软件程序是为了执行用户的某项活动，或是满足用户的某种需求。这些用户应用软件的问题区域就是软件的领域。
为了创建真正能为用户活动所用的软件，开发团队必须运用一整套与这些活动有关的知识体系。所需的知识广度可能令人望而生畏，庞大而复杂的信息也可能超乎想象。模型正是解决此类信息超载问题的工具。模型这种知识形式对知识进行了选择性的简化和有意的结构化。
领域模型并非是某种特殊的图，而是这种图所要传达的思想。它不单单是领域专家头脑中的知识，而是对这类知识严格的组织且有选择的抽象。图可以表达和传达一种模型，同样，精心书写的代码或文字也能达到同样的目的。
在领域驱动设计中，3个基本用途决定了模型的选择。
模型和设计的核心相互影响。确保我们在模型中所进行的分析能够转化为最终产品。可以基于对模型的理解来解释代码。模型是团队所有成员使用的用用语言的中枢。开发人员可以使用该语言来讨论程序。可以在无需翻译的情况下与领域专家进行沟通。模型是浓缩的知识。模型是团队一致认同的领域知识的组织方式和重要元素的区分方式。透过我们如何选择属于、分解概念以及将概念联系起来，模型记录了我们看待领域的方式。 软件的核心软件的核心是其为用户解决领域相关的问题的能力。
在一个团队中，对领域深层次理解的模型开发有时也会迷失方向，此时，理解领域核心的领导者能够将软件项目带回到正确的轨道上来。
开发人员可以采用一些系统性的思考方法来透彻理解领域并开发出有效的模型。还有一些设计技巧可以使毫无头绪的软件应用变得井井有条。
模型和实现的绑定。建立一种基于模型的语言。开发一个蕴含丰富知识的模型。
对象具有行为和强制性规则。模型并不仅仅是一种数据模式，它还是解决复杂问题不可或缺的部分。模型包含各种类型的知识。提炼模型。
在模型日趋完善的过程中，重要的概念不断被添加在模型中，但同样重要的是，不再使用的或不重要的概念则从模型被移除。当一个不需要的概念与一个需要的概念有关联时，则把重要的概念提取到一个新模型中，其他那些不要的概念就可以丢弃了。交流和实验。
语言和草图，再加入交流，将与需求方的沟通变成“模型实验室”，在这些讨论中可以演示、尝试和判断上百种变化。当团队在分步讨论场景时，口头表达本身就可以作为所提议的模型的可行性测试。
正是交流和大量的实验的创造力才使团队找到一个富含知识的模型并对它进行提炼，在这个过程中，基于模型的语言提供了很大帮助，而且贯穿整个实现过程中的反馈闭环也对模型起到了“训练”作用。这种 知识消化将团队的知识转化为有价值的模型。 知识消化
知识消化并非是一项孤立活动，它一般是在开发人员的领导下，由开发人员与领域专家组成的团队来共同协作。
领域模型不断精化迫使开发人员学习重要的业务原理。领域专家被迫提炼自己知道的重要知识的过程往往也是完善自身理解的过程。
分析员和程序员将自己的知识输入到了模型中，因此模型的组织更严密，抽象也更为简洁，从而为实现提供了更大的支持。同时，由于领域专家也将他们的知识输入到了模型中，因此，模型反映了业务深层次知识，而且真正的业务原则得以抽象。
模型在不断地改进的同时，也成为组织项目信息流的工具。模型聚焦于需求分析。与编程和设计紧密交互。通过良性循环加深团队成员对领域的理解，使他们透彻地理解模型。
模型对理解领域必须是切实可用的。它们必须非常精确，以便应用程序易于实现和理解。
持续学习当开始编写软件时，我们知之甚少。项目零散地分散在很多人和文档中，其中夹杂着其他一些无关信息。
高效率的团队需要有意识地积累知识，并持续学习。对于开发人员来说，这意味着既要完善技术知识，也要培养一些领域建模技巧。
业务活动和队则如同所涉及的实体一样，都是领域核心，任何领域都有各种类别的概念。知识消化所产生的模型能够反映出对知识的深层次理解。在模型发生改变的同时，开发人员对实现进行重构，以便反映出模型的变化，这样，新知识就被合并到应用程序中了。
深层模型有用的模型很少应留在表面。随着对领域和应用程序需求的理解和逐步加深，往往会丢弃那些最初看起来很重要的表面元素，或者切换它们的角度。这时，一些开始时不可能发现的巧妙抽象就会渐渐浮出水面，而它们恰恰切中问题的要害。
知识消化是一种探索，它永无止境。