领域模型是软件项目的公共语言的核心。模型是人们头脑中形成的与项目有关的概念集合，他用术语和关系反映了领域的深层含义。这些术语和相互关系提供了模型语言的语义，模型语义是专门为领域量身剪裁的，而且十分精确，以便支持技术开发。它是一条至关重要的纽带，将模型与开发活动结和在一起，并使模型与代码紧密绑定。
在一个没有公共语言的项目上，开发人员不得不为领域专家做翻译。而这些领域专家还需要充当开发人员与其他领域专家之间的翻译。甚至开发人员之间还需要互相翻译。这些翻译是模型概念变得混淆，这会破坏代码的重构。这间接的沟通掩盖了分裂的形成，不同的团队成员使用不同的技术语而尚不自知。这导致软件的各个部分不能够浑然一体，因此无法开发出可靠的软件。
如果语言支离破碎，项目必将遭遇严重问题。领域专家使用他们自己的行话，而技术团队成员则使用自己的的语言从设计角度讨论领域。
日常讨论所使用的术语与代码（软件项目的最重要产品）中使用的术语不一致。甚至同一个人在讲话和写东西时使用的语言也不一致，这导致的后果是，即使人们对领域有了一些深刻的描述，也转眼就忘记了，而无法记录到代码或者文档中。
翻译使得沟通不畅，并导致知识消化变得困难。
然而任何一种行话都不能成为公共语言，因为他们无法满足所有的需求。
项目需要一种公共语言，Ubiquitous Language（通用语言）。Ubiquitous Language的词汇表包括类名称和主要操作。Language中包含术语，有些术语用来讨论模型中已经明确的规则，还有一些术语则来施加于模型上的高级组织原则。
模型之间的关系成为所有语言都具有的组合规则。词和短语的意义反映了模型的语义。
尽管只是消化过程和基于模型的语言的使用看起来在次序上没有先后之分，但其实前者是依赖后者的，也就是说，有助于产生更有用模型的知识消化过程依赖于整个团队对使用基于模型语言的一直承诺。团队一致使用Ubiquitous Language可以博爱路触摸型中存在的缺点，这样团队就可以尝试并找到不浅当属于或组合词的替代词。当有些概念无法用现有语言中的词汇表达时，新的词语将被引入到讨论中。这些语言上的更改也会在领域模型中引起响应的更改，并促使团队更新类图并重命名代码中的类和方法，甚至在术语的意义改变时会导致行为也发生改变。
因此：将模型作为语言的中心。确保团队在所有交流活动和代码中坚持使用这种语言。在画图，写东西特别是讲话时也要使用这种语言。
通过尝试不同的表示方法（他们反映了不同模型）来消除难点。然后重构代码，并对类，方法和模块重命名，以便于新模型相一致。解决交谈中的术语混淆问题，就像我们对普通词汇形成一个工人的理解一样。
要认识到Ubiquitous Language中的更爱就是对模型的更改。
领域庄家应该避免使用拗口货物发表的领域理解的术语或结构，开发人员应该密切监视那些将会妨碍设计的有歧义和不一致的地方。
文档和图
有些人天生习惯于直观一些的表现方法，图可以帮助我们掌握一些信息。UML图非常擅于表达对象之间的关系，尤其擅长显示对象交互。但它们不会给出这些对象的概念的定义。
当人们必须要通过UML图表示整个模型或设计是，麻烦也随之而而来。喊队对象模型图在某些方面过于细致，同时在某些方面又有很多遗漏。说它们过于细致是因为人们认为必须将所有要编码的对象放到建模工具中。细节过多的结果是只见树木不见森林。
对象交互图可以掩饰设计中的一些复杂的要点，但却无法用这种方式来显示大部分交互，原因是工作量大。而且交互图只能按时触摸型的目的。要想把约束和断言包括进来，需要在UML中使用文本，这些文本用括号括起来，插入到图中。
UML也不是一种十分令人满意的编程语言。如果仅仅使用UML功能来建模，得到的模型往往会遗漏最关键的部分，因为有些规则并不适合用线框图来表示。如果使用UML作为实现语言，则仍然需要利用其他手段来表达模型的确切含义。
设计的重要细节应该在代码中体现出来。良好的实现应该是透明的，清楚地展示它的底层模型。互为补充的图和文档能够引导人们将注意力放在核心要点上。
务必要记住模型不是图。图的目的是帮助表达和解释模型。代码可以充当设计细节的存储库。清晰的java代码与UML具有同样的表达能力。经过仔细选择和构造的图可以帮助人们集中注意力，并起到指导作用，当然前提条件是不能青之完全用图来表示模型或设计，因为这样会削弱图的清晰表达的能力。