首先写个句子，
然后切成小片;
再把碎片混合，
好像偶然散落：
至于词句顺序
确实毫不重要。
—Lewis Carroll, “诗人非天生，练习可成就”
为了使设计既灵活又蕴含丰富的知识，团队需要使用一种通用的共享语言，并在真实环境中对其进行验证。不过，软件项目中很少能做到这一点。
在一个限界上下文中，如果我们不花精力进行完善的建模，语言就可能被打乱。如果模型仅用于团队技术人员绘制UML图，那么对于DDD的核心原则“创造性的协作”就没有什么用处了。
领域专家有自己的行话，而技术团队在设计时却使用不同的语言来讨论领域。日常讨论中所用的术语与写在代码中的术语是割裂的(这些代码最终会进入软件项目中最重要的产品)。即便是同一个人，在说和写时竟然也会用不同的语言。因此，最能深刻表达领域的语言往往只存在于短暂的讨论，却没有体现在代码中，甚至没有记录到书面的文档。
不同语言间的翻译使交流过程变得迟钝，使知识的理解缺乏内涵。
然而，并不能把行话直接变为通用语言，因为没有哪一种行话能满足所有人的需求。
领域专家应该避免使用那些难以理解或不能充分表达领域知识的术语和表达方式；开发人员应该注意语言中的含糊和不一致性，以免影响设计。
应该使用相同的方式讨论模型和系统。描述模型时，使用模型中的元素和交互方式大声地讲出来，这也是用模型允许的方式将概念组合在一起的过程。寻找更简单的方式进行表达，然后将其带回模型图和代码。
通过使用统一语言，模型将不再仅仅是设计过程的产出物，而是会嵌入到开发人员和领域专家协作完成的所有工作中。
因此：
将模型作为语言的基干。让团队在所有的交流以及代码中坚持使用这种语言。在一个限界上下文中画图、书写、尤其是谈话时使用相同的语言。
认识到改变语言就是在改变模型。
解决困难时，可试着使用不同的表达方式，不同的表达方式反映了不同的模型。然后重构代码，重命名类、方法和模块，以便符合新的模型。解决对话中术语的混淆，就像我们对普通词语的意思达成一致那样。