读Domain-Driven Design Tackling complexity in the heart of software
DDD中对建模的基本要求如下，首先模型和实现是相互绑定的，在我们当前的项目中可能会体会到，一般情况下我们用来与客户进行交流的是一套模型（偏向于用户易于理解的），而我们的系统实现时，我们架构出是另一套为我们技术人员用的也是我们经常接触的模型；基于模型生成了一种语言，也就是包含许多领域术语和一些技术术语的语言，以后的模型演化和业务讨论中，可以自由的运用这种语言组织成句子用来描述模型；模型包含丰富的知识，因为模型要解决复杂的领域问题而不仅仅是一个数据方案，对象都具有行为和约束；对于模型的提炼，随着模型的演化、完善，一些重要的概念被加入，同样重要的是，一些被发现无用或是累赘的概念应该被丢弃，模型始终是展现整个工程的实时的核心；运用头脑风暴加以简单实验创建并提炼模型，基于模式的语言及实现的反馈循环中约束则提供了支持。
关于知识消化，高效的领域建模人员是知识的消化器，他们寻求一种对大量冗杂信息有意义的简单视图，随着许多模型在实验后被抛弃，我们工作的意义在于我们的成果可以对已发现的最相关的特定知识的精确表达，也就是一组能够明确所有细节意义的抽象概念。而这个过程在DDD中的一个明显特点是，由开发团队和领域专家合作，由开发人员领导，一起接受信息并使之成为有用的形式，原始资料的来源可以是领域专家的意见、现有系统用户、相关老系统的技术团队经验或同一领域中的另一项目、大量的会谈、文档。传统瀑布方式中，“业务专家与分析人员会谈，分析人员提取摘要，进行抽象后将结果转达给开发人员，由开发人员对软件进行编码”，这种方法之所以不成功，是因为它完全没有反馈机制，分析人员仅仅从业务专家得到信息进行工作，他们没有机会从开发人员那里学习新知识或从软件早期版本获得经验，知识单向流动并没有交互积累。而使用迭代过程的项目没能有效创建新知识是因为他们没有对知识进行抽象，开发人员让业务专家描述功能然后构建它，展示结果并询问下一步工作，这只在开发人员对该领域较为熟悉时有效，即使可以构建出有用的软件，但是项目永远不会具有能够从前期特征推导出更加强大的新特征的的能力。而开发人员和分析人员的同时介入，使得模型组织有序并且抽象合理，也为实现提供了很大的支持，又因为领域专家介入其中，模型反映出业务的深层知识，可以抽象出真正的业务规则。作为反应需求的模型，其与编程和设计相互影响，应该是项目中信息交流的工具，模型是持续演进的，但模型对于领域来说必须是实用的，必须是精确的，使得应用程序易于实现和理解。
关于项目中文档，“代码就是文档”，XP一直是被提倡的，但这也是有局限的，书面文档、图、代码应该是相互补充的，其中小而精确的关键场景的UML图是必要的，模型并不是图，而图和文档则是为了在代码之外补充阐释模型的概念，代码和文档都应该使用模型的语言。
我们当前的实践中，总会让你感觉到兼有老方法和新过程的影子，毕竟项目实际的实践中总会有种种的客观因素存在，资源、风险等等。学习这些新的、被提倡的实践，可以让你站在另外一个高度或说角度去参与实践，无论使用什么样过程，好的实践总是可以借鉴的。
