# 建立领域通用语言
# 沟通障碍
软件专家和领域专家通力合作开发出一个领域的模型是绝对需要的，但是，那种方法通常会由于一些基础交流的障碍而存在难点。开发人员满脑子都是类、方法、算法、模式，总是想将实际生活中的概念和程序工件做对应。他们希望看到要建立哪些对象类，要如何对对象类之间的关系建模。他们会按照继承、多态、面向对象的编程等方式去思考，会随时随地这样交谈，这对他们来说这太正常不过了，开发人员就是开发人员。 但是领域专家通常对这一无所知。他们对软件类库、框架、持久化 甚至数据库没有什么概念。他们只了解他们特有的专业技能。
为克服这种交流方式的不同，在建立模型时，我们必须通过沟通来交换对模型和模型中涉及到的元素的想法，应该如何连接它们，哪些是有关的，哪些不是?在这种层次上的交流对一个成功的项目而言是极为重要的。如果一个人说了什么事情，其他的人不能理解， 或者更糟的是错误理解成其他事情，又有什么机会来保证项目成功呢?
当团队成员不能享用一个公共语言来讨论领域时，项目会面临严重的问题。领域专家使用自己的行话，技术团队成员在设计中也用自己的语言讨论领域。
在交流的过程中，需要做翻译才能让其他的人理解这些概念。开发人员可能会努力使用外行人的语言来解析一些设计模式，但这并一定都能成功奏效。领域专家也可能会创建一种新的行话以努力表达他们的这些想法。在这个痛苦的交流过程中，这种类型的翻译并不能对知识的构建过程产生帮助。
在讨论模型和定义模型时，我们确实需要讲同一种语言。那么是哪种语言呢?开发人员的语言?领域专家的语言?介乎两者之间的语言?
# 通用语言
领域驱动设计的一个核心的原则是使用一种基于模型的语言。因为模型是软件满足领域的共同点，它很适合作为这种通用语言的构造基础。
使用模型作为语言的核心骨架。要求团队在进行所有的交流是都使用一致的语言，在代码中也是这样。在共享知识和推敲模型时，团队会使用演讲、文字和图形。这儿需要确保团队使用的语言在所有的交流形式中看上去都是一致的。因为这个原因，这种语言被称为 “通用语言(Ubiquitous Language)”。
通用语言连接起设计中的所有的部分，建立了设计团队良好工作的前提。可能会花费数周乃至数月的时间才能让一个大规模项目的设计成型。团队成员会发现一些初始的概念是不正确的或者不合适宜，或者发现一些需要考虑并放进总体设计中的新的设计元素。没有了通用语言，所有的这一切都是不可能的。
怎么理解通用语言这个概念呢？**在事件风暴过程中，通过团队交流达成共识的，能够简单、清晰、准确描述业务涵义和规则的语言就是通用语言。**也就是说，通用语言是团队统一的语言，不管你在团队中承担什么角色，在同一个领域的软件生命周期里都使用统一的语言进行交流。通用语言可以解决交流障碍这个问题，使领域专家和开发人员能够协同合作，从而确保业务需求的正确表达。
通用语言包含术语和用例场景，并且能够直接反映在代码中。通用语言中的名词可以给领域对象命名，如商品、订单等，对应实体对象；而动词则表示一个动作或事件，如商品已下单、订单已付款等，对应领域事件或者命令。
通用语言贯穿 DDD 的整个设计过程。作为项目团队沟通和协商形成的统一语言，基于它，就能够开发出可读性更好的代码，将业务需求准确转化为代码设计。
- 在事件风暴的过程中，领域专家会和设计、开发人员一起建立领域模型，在领域建模的过程中会形成通用的业务术语和用户故事。事件风暴也是一个项目团队统一语言的过程。
- 通过用户故事分析会形成一个个的领域对象，这些领域对象对应领域模型的业务对象，每一个业务对象和领域对象都有通用的名词术语，并且一一映射。
- 微服务代码模型来源于领域模型，每个代码模型的代码对象跟领域对象一一对应。
设计过程中我们可以用一些数据字典，来记录事件风暴和微服务设计过程中产生的领域对象及其属性。比如，领域对象在 DDD 分层架构中的位置、属性、依赖关系以及与代码模型对象的映射关系等。数据字典中的这些名词术语就是项目团队在事件风暴过程中达成一致、可用于团队内部交流的通用语言。
DDD 分析和设计过程中的每一个环节都需要保证限界上下文内术语的统一，在代码模型设计的时侯就要建立领域对象和代码对象的一一映射，从而保证业务模型和代码模型的一致，实现业务语言与代码语言的统一。
如果建立了领域对象和代码对象的映射关系，那就可以指导软件开发人员准确无误地按照设计文档完成微服务开发了。即使是不熟悉代码的业务人员，也可以很快找到代码的位置。