1、通过通用语言达成共识
通用语言，已经强调过好多遍了，在DDD再怎么重视都不为过，后面可能还会讲。
知识提炼的输出以及共识的构建就是常见的通用语言(UL)。
当与业务相关人员和主题专家进行建模时，每个人都应该有意识地始终应用富含领域专有术语的通用语言。这一语言必须现实制作，并在描述领域模型和问题域时使用。该语言还应该用于模型的代码实现，使用用作类名、属性和方法名称相同的术语和概念。正是这一语言使得业务和开发团队拥有了关于软件的有意义沟通。
UL用于将模型的代码描述绑定到以业务能够理解的语言和图表交流的概念模型。这句话说了好多遍，再重复一次。
UL它将包含来自业务的专业术语 以及在进行问题域的用例建模时发现的新概念和术语。
UL能避免持续从技术模型转换到业务模型的情况，因而也就能避免出现遗漏掉必不可少的见解的情况。
UL是一个共识。
2、领域知识的重要性
领域知识是关键，其重要性甚至要远甚于技术知识。
要处理具有复杂过程和逻辑 的业务 的团队需要将自身沉浸在问题域中，学习吸收所以相关的领域知识。这样让团队能够专注在要点上，并在其开发的应用程序代码库核心处创建一个能够满足业务用例的模型。而且在整个应用程序的生命周期中都要保持这样的做法。
如果不能用简单术语向你的业务用户讲诉问题域中的复杂概念，那么无法做好开始在其中开发软件的准备。
要为你正在构建的复杂应用程序 快速地持续发布更新(即便是在稀奇古怪的业务要求，或变化无常的功能时)，就需要你在设计和开发期间重新调整你的精力倾注点——需要让你的团队专注于业务问题，而不是仅仅是技术。
3、一个持续的过程
知识提炼是一个持续的过程；团队应该持续地为问题域的简单视图而努力，该简单视图只专注于相关内容以便实现创建有用模型的目标。模型驱动设计和领域模型的演化是一个持续过程。
开发团队、业务相关人员以及主题专家之间的协作不应该局限在项目开始阶段。知识提炼在整个应用程序构建的生命周期中应该在业务参与的情况下被持续关注。
认识到随着系统的每一次迭代，模型都会有所演化，这一点也是很重要。模型永远不会尽善尽美，它只是对于当前问题可用而已。因为，当新的需求被添加进来时，模型就会改变；新的行为和用例也将需要模型的改变。
随着每一次的迭代完成，团队对于问题域的理解都会提升。这将带来 能够极大简化模型的更深刻的见解以及设计突破。
在系统投入使用时，模型可能也需要演化，这是由像 性能或对系统用途的更好理解 这样一些技术原因造成的。
一个好的模型要能够足够灵活以支持变更；一个成熟的模型会保有丰富且传神的概念以及问题域的专业术语，并且能同时业务和技术团队所理解。