It’s developers’ (mis)understanding, not domain experts’ knowledge, that gets released in production. —Alberto Brandolini
在产品中发布的是开发人员的(错误的)理解，而不是领域专家的知识。——Alberto Brandolini
In the previous chapter, we started exploring business domains. You learned how to identify a company’s business domains, or areas of activity, and analyze its strategy to compete in them; that is, its business subdomains’ boundaries and types.
在上一章中，我们开始探索业务领域。您学习了如何识别一个公司的业务领域或活动领域，并分析其在这些领域中的竞争策略; 即其业务子域的边界和类型。
This chapter continues the topic of business domain analysis but in a different dimension: depth. It focuses on what happens inside a subdomain: its business function and logic. You will learn the domain-driven design tool for effective communication and knowledge sharing: the ubiquitous language. Here we will use it to learn the intricacies of business domains. Later in the book we will use it to model and implement their business logic in software.
本章继续讨论业务领域分析的主题，但是是在一个不同的维度上: 深度。它关注子域内发生的事情: 它的业务功能和逻辑。你将学到有效沟通和知识共享的领域驱动设计工具: 通用语言。在这里，我们将使用它来学习错综复杂的业务领域。在本书的后面，我们将使用它来在软件中建模和实现它们的业务逻辑。
Business Problems
业务问题
The software systems we are building are solutions to business problems. In this context, the word problem doesn’t resemble a mathematical problem or a riddle that you can solve and be done with. In the context of business domains, “problem” has a broader meaning. A business problem can be challenges associated with optimizing workflows and processes, minimizing manual labor, managing resources, supporting decisions, managing data, and so on.
我们正在构建的软件系统是业务问题的解决方案。在这种情况下，单词“问题”不像一个数学问题或谜语，你可以解决和完成。在业务领域的上下文中，“问题”具有更广泛的含义。业务问题可能是与优化工作流和流程、最小化手工劳动、管理资源、支持决策、管理数据等相关的挑战。
Business problems appear both at the business domain and subdomain levels. A company’s goal is to provide a solution for its customers’ problems. Going back to the FedEx example in Chapter 1, that company’s customers need to ship packages in limited time frames, so it optimizes the shipping process.
业务问题同时出现在业务领域和子域级别。公司的目标是为客户的问题提供解决方案。回到第一章中的联邦快递例子，该公司的客户需要在有限的时间内运送包裹，因此它优化了运送流程。
Subdomains are finer-grained problem domains whose goal is to provide solutions for specific business capabilities. A knowledge management subdomain optimizes the process of storing and retrieving information. A clearing subdomain optimizes the process of executing financial transactions. An accounting subdomain keeps track of the company’s funds.
子域是更细粒度的问题域，其目标是为特定的业务能力提供解决方案。知识管理子域优化了信息的存储和检索过程。结算子域优化了经济交易的执行过程。会计子域记录公司的资金情况。
Knowledge Discovery
知识发现
To design an effective software solution, we have to grasp at least the basic knowledge of the business domain. As we discussed in Chapter 1, this knowledge belongs to domain experts: it’s their job to specialize in and comprehend all the intricacies of the business domain. By no means should we, nor can we, become domain experts. That said, it’s crucial for us to understand domain experts and to use the same business terminology they use.
为了设计一个有效的软件解决方案，我们必须至少掌握业务领域的基本知识。正如我们在第1章中所讨论的，这些知识属于领域专家: 他们的工作是专门研究和理解业务领域的所有复杂性。我们决不应该，也不可能成为领域专家。也就是说，了解领域专家并使用他们使用的相同业务术语，对我们来说是至关重要的。
To be effective, the software has to mimic the domain experts’ way of thinking about the problem—their mental models. Without an understanding of the business problem and the reasoning behind the requirements, our solutions will be limited to “translating” business requirements into source code. What if the requirements miss a crucial edge case? Or fail to describe a business concept, limiting our ability to implement a model that will support future requirements?
为了有效，软件必须模仿领域专家思考问题的方式——他们脑子里的模型。如果不理解业务问题和需求背后的逻辑推理，我们的解决方案将仅限于将业务需求“转换”为源代码。如果需求遗漏了一个关键的边界情况，该怎么办？或者未能描述业务概念，从而限制了我们实现支持未来需求的模型的能力？
As Alberto Brandolini says, software development is a learning process; working code is a side effect. A software project’s success depends on the effectiveness of knowledge sharing between domain experts and software engineers. We have to understand the problem in order to solve it.
正如 Alberto Brandolini 所说，软件开发是一个学习过程; 编写代码是一个副作用。软件项目的成功取决于领域专家和软件工程师之间知识共享的有效性。我们必须了解问题以便解决它。
Effective knowledge sharing between domain experts and software engineers requires effective communication. Let’s take a look at the common impediments to effective communication in software projects.
领域专家和软件工程师之间有效的知识共享需要有效的沟通。让我们看看在软件项目中有效沟通的常见障碍。
Communication
沟通
It’s safe to say that almost all software projects require the collaboration of stakeholders in different roles: domain experts, product owners, engineers, UI and UX designers, project managers, testers, analysts, and others. As in any collaborative effort, the outcome depends on how well all those parties can work together. For example, do all stakeholders agree on what problem is being solved? What about the solution they are building—do they hold any conflicting assumptions about its functional and nonfunctional requirements? Agreement and alignment on all project-related matters are essential to a project’s success.
可以肯定地说，几乎所有的软件项目都需要不同角色的涉众之间的协作：领域专家、产品经理、工程师、 UI 和 UX 设计师、项目经理、测试人员、分析师等等。正如任何合作努力一样，结果取决于所有这些相关人能够共同工作得多好。例如，是否所有利益相关者都对正在解决什么问题保持一致？那么他们正在构建的解决方案呢? 他们是否对其功能性和非功能性需求持有任何相互矛盾的假设？所有项目相关事项中达成一致和协调对于项目的成功至关重要。
Research into why software projects fail has shown that effective communication is essential for knowledge sharing and project success. Yet, despite its importance, effective communication is rarely observed in software projects. Often, businesspeople and engineers have no direct interaction with one another. Instead, domain knowledge is pushed down from domain experts to engineers. It is delivered through people playing the role of mediators, or “translators,” systems/business analysts, product owners, and project managers. Such common knowledge sharing flow is illustrated in Figure 2-1.
对软件项目失败原因的研究表明，有效的沟通对于知识共享和项目成功至关重要。然而，尽管它很重要，有效的沟通在软件项目中却很少被重视。 通常，业务人员和工程师之间没有直接的交互。相反，领域知识是从领域专家推到工程师。它是通过扮演中介者或“翻译者”、系统/业务分析师、产品所有者和项目经理的角色来传递的。这种常见的知识共享流程如图2-1所示。
Figure 2-1. Knowledge sharing flow in a software project
图2-1 软件项目中的知识共享流
During the traditional software development lifecycle, the domain knowledge is “translated” into an engineer-friendly form known as an analysis model, which is a description of the system’s requirements rather than an understanding of the business domain behind it. While the intentions may be good, such mediation is hazardous to knowledge sharing. In any translation, information is lost; in this case, domain knowledge that is essential for solving business problems gets lost on its way to the software engineers. This is not the only such translation on a typical software project. The analysis model is translated into the software design model (a software design document, which is translated into an implementation model or the source code itself). As often happens, documents go out of date quickly. The source code is used to communicate business domain knowledge to software engineers who will maintain the project later. Figure 2-2 illustrates the different translations needed for domain knowledge to be implemented in code.
在传统的软件开发生命周期中，领域知识被“转化”为工程师友好的形式，称为分析模型，它是对系统需求的描述，而不是对其背后业务领域的理解。虽然意图可能是好的，但这种中介对知识共享是有害的。在任何翻译过程中，信息都会丢失; 在这种情况下，解决业务问题所必需的领域知识会在传递给软件工程师的过程中丢失。在一个典型的软件项目中，这并不是唯一的翻译。分析模型被翻译成软件设计模型(软件设计文档，它被翻译成实现模型或源代码本身)。正如经常发生的那样，文档很快就过时了。源代码用于将业务领域知识传达给软件工程师，后者将在以后维护项目。图2-2说明了在代码中实现领域知识所需的不同翻译。
Figure 2-2. Model transformations
图2-2. 模型转换
Such a software development process resembles the children’s game Telephone: the message, or domain knowledge, often becomes distorted. The information leads to software engineers implementing the wrong solution, or the right solution but to the wrong problems. In either case, the outcome is the same: a failed software project.
这样的软件开发过程类似于儿童游戏电话: 消息，或领域知识，往往产生偏差。这些信息会导致软件工程师实现错误的解决方案，或者正确的解决方案但是解决了错误的问题。无论哪种情况，结果都是相同的: 一个失败的软件项目。
Domain-driven design proposes a better way to get the knowledge from domain experts to software engineers: by using a ubiquitous language.
领域驱动设计提出了一个（软件工程师从领域专家处获取知识的）更好方法: 使用通用语言。
What Is a Ubiquitous Language?
通用语言是什么？
Using a ubiquitous language is the cornerstone practice of domain-driven design. The idea is simple and straightforward: if parties need to communicate efficiently, instead of relying on translations, they have to speak the same language.
使用一种通用语言是领域驱动设计的基础实践。这个想法简单明了: 如果各方需要有效沟通，而不是依赖翻译，他们必须说同一种语言。
Although this notion is borderline common sense, as Voltaire said, “common sense is not so common.” The traditional software development lifecycle implies the following translations:
正如伏尔泰所说，尽管这个概念是边缘型常识，但“常识并不那么常见。”传统的软件开发生命周期意味着以下翻译：
- Domain knowledge into an analysis model 领域知识转化为分析模型
- Analysis model into requirements 分析模型转化为需求
- Requirements into system design 需求转化为系统设计
- System design into source code 系统设计转化为源代码
Instead of continuously translating domain knowledge, domain-driven design calls for cultivating a single language for describing the business domain: the ubiquitous language.
与其不断地翻译领域知识，领域驱动设计呼吁培养一种描述业务领域的单一语言: 通用语言。
All project-related stakeholders—software engineers, product owners, domain experts, UI/UX designers—should use the ubiquitous language when describing the business domain. Most importantly, domain experts must be comfortable using the ubiquitous language when reasoning about the business domain; this language will represent both the business domain and the domain experts’ mental models.
所有与项目相关的利益相关者——软件工程师、产品所有者、领域专家、 UI/UX 设计师——在描述业务领域时应该使用通用语言。最重要的是，在推理业务领域时，领域专家必须能够轻松地使用通用语言; 这种语言将同时表示业务领域和领域专家的脑海中的模型。
Only through the continuous use of the ubiquitous language and its terms can a shared understanding among all of the project’s stakeholders be cultivated.
只有通过持续使用通用语言及其术语，才能培养项目所有利益相关者之间的共同理解。
Language of the Business
业务语言
It’s crucial to emphasize that the ubiquitous language is the language of the business. As such, it should consist of business domain–related terms only. No technical jargon! Teaching business domain experts about singletons and abstract factories is not your goal. The ubiquitous language aims to frame the domain experts’ understanding and mental models of the business domain in terms that are easy to understand.
强调通用语言是业务语言是至关重要的。因此，它应该只包含与业务领域相关的术语。没有技术术语! 教授业务领域专家关于单例和抽象工厂的知识不是你的目标。通用语言旨在以容易理解的方式框定领域专家对业务领域的理解和他脑海中的模型。
Scenarios
场景
Let’s say we are working on an advertising campaign management system. Consider the following statements:
假设我们正在开发一个广告活动管理系统，请思考以下陈述:
- An advertising campaign can display different creative materials. 广告活动可以展示不同的创意素材。
- A campaign can be published only if at least one of its placements is active. 一个广告活动只有在其中至少一个广告位置处于活动状态时才能发布。
- Sales commissions are accounted for after transactions are approved. 销售佣金在交易批准后入帐。
All of these statements are formulated in the language of the business. That is, they reflect the domain experts’ view of the business domain.
所有这些声明都是用业务的语言表述的。也就是说，它们反映了领域专家对业务领域的看法。
On the other hand, the following statements are strictly technical and thus do not fit the notion of the ubiquitous language:
另一方面，以下陈述是纯技术性的，因此不符合通用语言的概念:
- The advertisement iframe displays an HTML file. 广告 iframe 显示一个 HTML 文件。
- A campaign can be published only if it has at least one associated record in the active-placements table. 活动只有在活动位置表中至少有一条相关记录时才能发布。
- Sales commissions are based on correlated records from the transactions and approved-sales tables. 销售佣金是取决于相关的（交易和批准的销售表）记录。
These latter statements are purely technical and will be unclear to domain experts. Suppose engineers are only familiar with this technical, solution-oriented view of the business domain. In that case, they won’t be able to completely understand the business logic or why it operates the way it does, which will limit their ability to model and implement an effective solution.
这些后面的表述纯粹是技术性的，对于领域专家来说并不清楚。假设工程师只熟悉业务领域的这种面向解决方案的技术视图。在这种情况下，他们将无法完全理解业务逻辑或者业务逻辑为什么以这种方式运行，这将限制他们建模和实现有效解决方案的能力。
Consistency
一致性
The ubiquitous language must be precise and consistent. It should eliminate the need for assumptions and should make the business domain’s logic explicit.
通用语言必须是精确和一致的。它应该消除对假设的需要，并且应该使业务域的逻辑显式化。
Since ambiguity hinders communication, each term of the ubiquitous language should have one and only one meaning. Let’s look at a few examples of unclear terminology and how it can be improved.
由于歧义妨碍沟通交流，通用语言的每个术语都应该有一个而且只有一个含义。让我们看一些术语不清楚的例子，以及如何改进它。
Ambiguous terms
有歧义词语
Let’s say that in some business domain, the term policy has multiple meanings: it can mean a regulatory rule or an insurance contract. The exact meaning can be worked out in human-to-human interaction, depending on the context. Software, however, doesn’t cope well with ambiguity, and it can be cumbersome and challenging to model the “policy” entity in code.
假设在某些业务领域中，术语 “policy” 具有多重含义: 它可以表示监管规则或保险合同。确切的含义可以在人与人之间的互动中得出，这取决于环境。然而，软件不能很好地处理模糊性，并且在代码中建模“policy”实体可能会很麻烦和具有挑战性。
Ubiquitous language demands a single meaning for each term, so “policy” should be modeled explicitly using the two terms regulatory rule and insurance contract.
通用语言要求每个术语都有一个单一的含义，因此应该使用两个术语监管规则和保险合同对“policy”进行显式建模。
Synonymous terms
同义词
Two terms cannot be used interchangeably in a ubiquitous language. For example, many systems use the term user. However, a careful examination of the domain experts’ lingo may reveal that user and other terms are used interchangeably: for example, user, visitor, administrator, account, etc.
在一种通用语言中，两个术语不能互换使用。例如，许多系统使用术语user。然而，仔细研究领域专家的行话可能会发现，user和其他术语可以互换使用: 例如，user（用户）、visitor（访问者）、administrator（管理员）、account（帐户）等。
Synonymous terms can seem harmless at first. However, in most cases, they denote different concepts. In this example, both visitor and account technically refer to the system’s users; however, in most systems, unregistered and registered users represent different roles and have different behaviors. For example, the “visitors” data is used mainly for analysis purposes, whereas “accounts” actually uses the system and its functionality.
同义词一开始可能看起来无害，但在大多数情况下，它们表示不同的概念。在这个示例中，visitor（访问者）和account（帐户）在技术上都指的是系统的用户; 然而，在大多数系统中，未注册和已注册的用户代表不同的角色，具有不同的行为。例如，“访问者”数据主要用于分析目的，而“帐户”实际上使用系统及其功能。
It is preferable to use each term explicitly in its specific context. Understanding the differences between the terms in use allows for building simpler and clearer models and implementations of the business domain’s entities.
最好在特定的上下文中明确地使用每个术语。理解使用的术语之间的差异可以构建更简单、更清晰的业务领域实体模型并实现。
Model of the Business Domain
业务领域模型
Now let’s look at the ubiquitous language from a different perspective: modeling.
现在，让我们从不同的角度来看看这种通用语言: 建模。
What Is a Model?
模型是什么？
A model is a simplified representation of a thing or phenomenon that intentionally emphasizes certain aspects while ignoring others. Abstraction with a specific use in mind. —Rebecca Wirfs-Brock
模型是对事物或现象的简化表示，它有意强调某些方面而忽略其他方面。具有特定用途的抽象。——Rebecca Wirfs-Brock
A model is not a copy of the real world but a human construct that helps us make sense of real-world systems.
模型不是现实世界的复制品，而是帮助我们理解现实世界系统的人类构造。
A canonical example of a model is a map. Any map is a model, including navigation maps, terrain maps, world maps, subway maps, and others, as shown in Figure 2-3.
模型的规范示例是地图。任何地图都是一个模型，包括导航地图、地形图、世界地图、地铁地图和其他地图，如图2-3所示。
Figure 2-3. Different types of maps displaying different models of the earth: roads, time zones, nautical navigation, terrain, aeronautical navigation, and subway routes.
图2-3. 不同类型的地图显示不同的地球模型: 道路，时区，航海导航，地形，航空导航和地铁路线。
None of these maps represents all the details of our planet. Instead, each map contains just enough data to support its particular purpose: the problem it is supposed to solve.
这些地图没有一张能代表我们星球的全部细节。相反，每张地图只包含足够的数据来支持它的特定目的: 它应该解决的问题。
Effective Modeling
有效建模
All models have a purpose, and an effective model contains only the details needed to fulfill its purpose. For example, you won’t see subway stops on a world map. On the other hand, you cannot use a subway map to estimate distances. Each map contains just the information it is supposed to provide.
所有的模型都有一个目的，一个有效的模型只包含实现其目的所需的细节。例如，你不会在世界地图上看到地铁站。另一方面，你不能使用地铁地图来估计距离。每张地图只包含它应该提供的信息。
This point is worth reiterating: a useful model is not a copy of the real world. Instead, a model is intended to solve a problem, and it should provide just enough information for that purpose. Or, as statistician George Box put it, “All models are wrong, but some are useful.”
这一点值得重申: 一个有用的模型不是现实世界的复制品。相反，模型的目的是解决问题，它应该为此目的提供足够的信息。或者，正如统计学家乔治•博克斯(George Box)所言: “所有模型都是错误的，但有些是有用的。”
In its essence, a model is an abstraction. The notion of abstraction allows us to handle complexity by omitting unnecessary details and leaving only what’s needed for solving the problem at hand. On the other hand, an ineffective abstraction removes necessary information or produces noise by leaving what’s not required. As noted by Edsger W. Dijkstra in his paper “The Humble Programmer,” the purpose of abstracting is not to be vague but to create a new semantic level in which one can be absolutely precise.
从本质上讲，模型是一种抽象。抽象的概念允许我们通过省略不必要的细节，只留下解决问题所需的东西来应对复杂性。另一方面，无效的抽象通过留下不需要的东西来消除必要的信息或产生噪音。正如艾兹赫尔·戴克斯特拉在他的论文《谦逊的程序员》中指出的那样，抽象的目的不是含糊不清，而是创造一个新的语义层面，在这个层面上可以做到绝对精确。
Modeling the Business Domain
业务领域建模
When cultivating a ubiquitous language, we are effectively building a model of the business domain. The model is supposed to capture the domain experts’ mental models—their thought processes about how the business works to implement its function. The model has to reflect the involved business entities and their behavior, cause and effect relationships, and invariants.
在培养一种通用语言时，我们实际上是在构建业务领域的模型。该模型旨在捕捉领域专家脑海里的模型——他们关于业务如何运作以实现其功能的思维过程。模型必须反映所涉及的业务实体及其行为、因果关系和不变量。
The ubiquitous language we use is not supposed to cover every possible detail of the domain. That would be equivalent to making every stakeholder a domain expert. Instead, the model is supposed to include just enough aspects of the business domain to make it possible to implement the 4 required system; that is, to address the specific problem the software is intended to solve. In the following chapters, you will see how the ubiquitous language can drive low-level design and implementation decisions.
我们使用的通用语言不应该涵盖领域的每一个可能的细节。这相当于让每个利益相关者都成为领域专家。相反，该模型应该包含业务领域的足够多的方面，以使实现4个必需的系统成为可能; 也就是说，解决软件要解决的特定问题。在接下来的章节中，您将看到通用语言是如何驱动底层设计和实现决策的。
Effective communication between engineering teams and domain experts is vital. The importance of this communication grows with the complexity of the business domain. The more complex the business domain is, the harder it is to model and implement its business logic in code. Even a slight misunderstanding of a complicated business domain, or its underlying principles, will inadvertently lead to an implementation prone to severe bugs. The only reliable way to verify a business domain’s understanding is to converse with domain experts and do it in the language they understand: the language of the business.
工程团队和领域专家之间的有效沟通至关重要。这种沟通的重要性随着业务领域的复杂性而增长。业务领域越复杂，就越难以在代码中建模和实现其业务逻辑。即使对复杂的业务领域或其基本原则略有误解，也会不经意地导致实现可能出现严重错误。验证业务领域理解程度的唯一可靠方法是与领域专家进行交流，并使用他们理解的语言: 业务语言。
Continuous Effort
坚持不懈的努力
Formulation of a ubiquitous language requires interaction with its natural holders, the domain experts. Only interactions with actual domain experts can uncover inaccuracies, wrong assumptions, or an overall flawed understanding of the business domain.
要建立一种通用语言，需要与其自然持有者，即领域专家进行交流合作。只有与实际的领域专家进行交流合作，才能揭示不准确、错误的假设或对业务领域的整体错误理解。
All stakeholders should consistently use the ubiquitous language in all project-related communications to spread knowledge about and foster a shared understanding of the business domain. The language should be continuously reinforced throughout the project: requirements, tests, documentation, and even the source code itself should use this language.
所有涉众都应该在所有与项目相关的沟通中始终使用通用语言，以传播关于业务领域的知识并促进对业务领域的共同理解。这种语言应该在整个项目中不断加强: 需求、测试、文档，甚至源代码本身都应该使用这种语言。
Most importantly, cultivation of a ubiquitous language is an ongoing process. It should be constantly validated and evolved. Everyday use of the language will, over time, reveal deeper insights into the business domain. When such breakthroughs happen, the ubiquitous language must evolve to keep pace with the newly acquired domain knowledge.
最重要的是，培养一种通用语言是一个持续的过程。它应该不断得到验证和发展。随着时间的推移，该语言的日常使用将揭示对业务领域的更深层次的见解。当这样的突破发生时，通用语言必须演变以跟上新获得的领域知识。
Tools
工具
There are tools and technologies that can alleviate the processes of capturing and managing a ubiquitous language.
有一些工具和技术可以在捕捉和管理通用语言的过程中提供帮助。
For example, a wiki can be used as a glossary to capture and document the ubiquitous language. Such a glossary alleviates the onboarding process of new team members, as it serves as a go-to place for information about the business domain’s terminology.
例如，维基可以用作一个词汇表，捕捉和记录通用语言。这样的词汇表加速了新团队成员的加入过程，因为它可以作为关于业务领域术语的信息的首选地点。
It’s important to make glossary maintenance a shared effort. When a ubiquitous language is changed, all team members should be encouraged to go ahead and update the glossary. That’s contrary to a centralized approach, in which only team leaders or architects are in charge of maintaining the glossary.
将词汇表维护作为一项共享工作是很重要的。当一种通用语言发生更改时，应该鼓励所有团队成员继续更新词汇表。这与集中式方法相反，在集中式方法中，只有团队领导或架构师负责维护词汇表。
Despite the obvious advantages of maintaining a glossary of project-related terminology, it has an inherent limitation. Glossaries work best for “nouns”: names of entities, processes, roles, and so on. Although nouns are important, capturing the behavior is crucial. The behavior is not a mere list of verbs associated with nouns, but the actual business logic, with its rules, assumptions, and invariants. Such concepts are much harder to document in a glossary. Hence, glossaries are best used in tandem with other tools that are better suited to capture the behavior; for example, use cases or Gherkin tests.
尽管维护项目相关术语的词汇表有明显的优势，但它具有固有的局限性。词汇表最适合“名词”：实体、流程、角色等的名称。尽管名词很重要，但捕获行为至关重要。行为不仅仅是与名词相关的动词列表，而是实际的业务逻辑，其中包括规则、假设和不变性。这种概念很难在词汇表中进行记录。因此，最好将词汇表与其他更适合捕获行为的工具配合使用；例如，使用用例或Gherkin测试。
Automated tests written in the Gherkin language are not only great tools for capturing the ubiquitous language but also act as an additional tool for bridging the gap between domain experts and software engineers. Domain experts can read the tests and verify the system’s expected behavior. For example, see the following test written in the Gherkin language:
Gherkin语言编写的自动化测试不仅是捕获通用语言的好工具，而且还可以作为一种附加工具来弥合领域专家和软件工程师之间的知识鸿沟。领域专家可以阅读测试并核实系统的预期行为。例如，下面使用Gherkin语言编写的测试：
Scenario: Notify the agent about a new support case Given Vincent Jules submits a new support case saying: """ I need help configuring AWS Infinidash """ When the ticket is assigned to Mr. Wolf Then the agent receives a notification about the new ticket
Managing a Gherkin-based test suite can be challenging at times, especially at the early stages of a project. However, it is definitely worth it for complex business domains.
管理一个基于 Gherkin 的测试套件有时候很有挑战性，特别是在项目的早期阶段。然而，对于复杂的业务领域来说，这绝对是值得的。
Finally, there are even static code analysis tools that can verify the usage of a ubiquitous language’s terms. A notable example for such a tool is NDepend.
最后，甚至还有一些静态代码分析工具可以验证一种通用语言的术语的使用。这种工具的一个著名例子是 NDepend。
While these tools are useful, they are secondary to the actual use of a ubiquitous language in day-to-day interactions. Use the tools to support the management of the ubiquitous language, but don’t expect the documentation to replace the actual usage. As the Agile Manifesto says, “Individuals and interactions over processes and tools.”
这些工具虽然是有用的，但它们都是次要的，通用语言在日常交流中才是主要的运用。使用这些工具来辅助通用语言的管理，但不要指望文档可以取代实际的使用。正如敏捷宣言所说：“个体与互动胜过流程和工具”。
Challenges
挑战
In theory, cultivating a ubiquitous language sounds like a simple, straightforward process. In practice, it isn’t. The only reliable way to gather domain knowledge is to converse with domain experts. Quite often, the most important knowledge is tacit. It’s not documented or codified but resides only in the minds of domain experts. The only way to access it is to ask questions.
从理论上讲，培养一种通用语言听起来是一个简单、直截了当的过程。实际上，并非如此。收集领域知识的唯一可靠方法是与领域专家交流。很多时候，最重要的知识是心照不宣的。它没有被记录或编纂，只存在于领域专家的头脑中。访问它们的唯一方法就是向领域专家提问。
As you gain experience in this practice, you will notice that frequently, this process involves not merely discovering knowledge that is already there, but rather co-creating the model in tandem with domain experts. There may be ambiguities and even white spots in domain experts’ own understanding of the business domain; for example, defining only the “happy path” scenarios but not considering edge cases that challenge the accepted assumptions. Furthermore, you may encounter business domain concepts that lack explicit definitions. Asking questions about the nature of the business domain often makes such implicit conflicts and white spots explicit. This is especially common for core subdomains. In such a case, the learning process is mutual—you are helping the domain experts better understand their field.
随着在这种实践中的经验的增加，您会注意到，这个过程往往不仅仅是发现已经存在的知识，而是与领域专家共同创造模型。领域专家对业务领域的理解自身可能存在歧义，甚至白点；例如，只定义“快乐路径”场景，而不考虑挑战公认假设的边缘情况。此外，您可能会遇到缺乏明确定义的业务领域概念。就业务领域的性质提出问题往往会使这种隐式冲突和白点明确化。这在核心子域中尤其常见。在这种情况下，学习过程是双向的——您正在帮助领域专家更好地理解他们的领域。
When introducing domain-driven design practices to a brownfield project, you will notice that there is already a formed language for describing the business domain, and that the stakeholders use it. However, since DDD principles do not drive that language, it won’t necessarily reflect the business domain effectively. For example, it may use technical terms, such as database table names. Changing a language that is already being used in an organization is not easy. The essential tool in such a situation is patience. You need to make sure the correct language is used where it’s easy to control it: in the documentation and source code.
在将领域驱动设计实践引入棕地项目时，你会发现已经有一种模式化的语言来描述业务领域，并且相关利益相关者正在使用它。然而，由于DDD原则没有驱动这种语言，它不一定能有效地反映业务领域。例如，它可能使用技术术语，如数据库表名。改变一个已经在组织中使用的语言并不容易。这种情况下的基本工具是耐心。你需要确保在易于控制的地方使用正确的语言：在文档和源代码中。
Finally, the question about the ubiquitous language that I am asked often at conferences is what language should we use if the company is not in an English-speaking country. My advice is to at least use English nouns for naming the business domain’s entities. This will alleviate using the same terminology in code.
最后，我在会议上经常被问到的关于通用语言的问题是，如果公司不在一个讲英语的国家，我们应该使用哪种语言。我的建议是至少使用英语名词来命名业务领域的实体。这将减轻在代码中使用相同术语的问题。
Conclusion
总结
Effective communication and knowledge sharing are crucial for a successful software project. Software engineers have to understand the business domain in order to design and build a software solution.
有效的沟通和知识共享对于成功的软件项目至关重要。软件工程师必须理解业务领域才能设计和构建软件解决方案。
Domain-driven design’s ubiquitous language is an effective tool for bridging the knowledge gap between domain experts and software engineers. It fosters communication and knowledge sharing by cultivating a shared language that can be used by all the stakeholders throughout the project: in conversations, documentation, tests, diagrams, source code, and so on.
领域驱动设计的通用语言是一种有效的工具，可以弥合领域专家和软件工程师之间的知识鸿沟。它通过培养一种可供项目中所有涉众使用的共享语言来促进沟通和知识共享: 包括会话、文档、测试、图表、源代码等等。
To ensure effective communication, the ubiquitous language has to eliminate ambiguities and implicit assumptions. All of a language’s terms have to be consistent—no ambiguous terms and no synonymous terms.
为了确保有效的交流，通用语言必须消除歧义和隐含的假设。一种语言的所有术语都必须是一致的——没有含糊不清的术语，也没有同义术语。
Cultivating a ubiquitous language is a continuous process. As the project evolves, more domain knowledge will be discovered. It’s important for such insights to be reflected in the ubiquitous language.
培养一种通用语言是一个持续的过程。随着项目的发展，将会发现更多的领域知识。重要的是，这些见解要反映在通用语言中。
Tools such as wiki-based glossaries and Gherkin tests can greatly alleviate the process of documenting and maintaining a ubiquitous language. However, the main prerequisite for an effective ubiquitous language is usage: the language has to be used consistently in all project-related communications.
基于 wiki 的词汇表和 Gherkin 测试等工具可以极大地减轻编写文档和维护通用语言的过程。然而，有效的通用语言的主要先决条件是使用：该语言必须在所有与项目相关的沟通中得到一致的使用。
Exercises
练习
1. Who should be able to contribute to the definition of a ubiquitous language? 谁应该能够为一种通用语言的定义做出贡献？
a. Domain experts 领域专家
b. Software engineers 软件工程师
c. End users 最终用户
d. All of the project’s stakeholders 项目的所有利益相关者
答案：d。All of the project’s stakeholders should contribute their knowledge and understanding of the business domain. 项目的所有涉众都应该贡献他们对业务领域的知识和理解。
2. Where should a ubiquitous language be used? 通用语言应该在哪里使用？
a. In-person conversations 面对面谈话
b. Documentation 文档
c. Code 代码
d. All of the above 以上都是
答案：d。A ubiquitous language should be used in all project-related communication. The software’s source code should also “speak” its ubiquitous language. 一种通用语言应该用于所有与项目相关的交流，软件的源代码也应该“说”它的通用语言。
3. Please review the description of the fictional WolfDesk company in the Preface. What business domain terminology can you spot in the description? 请回顾前言中虚构的 WolfDesk 公司的描述。您能在描述中发现哪些业务领域术语？
答案：
WolfDesk’s customers are tenants. To start using the system, tenants go through a quick onboarding process. The company’s charging model is based on the number of tickets that were opened during a charging period. The ticket lifecycle management algorithm ensures that inactive tickets are automatically closed. WolfDesk’s fraud detection algorithm prevents tenants from abusing its business model. The support autopilot functionality tries to find solutions for new tickets automatically. A ticket belongs to a support category and is associated with a product for which the tenant provides support. A support agent can only process tickets during their work time, which is defined by their shift schedules
WolfDesk 的客户都是租户。要开始使用该系统，租户需要经历一个快速上岗计划过程。该公司的收费模式是基于在收费期间打开的工单数量。工单生命周期管理算法确保非活动工单自动关闭。WolfDesk 的欺诈检测算法可以防止租户滥用其业务模型。自动支持功能尝试自动为新工单找到解决方案。一个工单分属为某个支持类别，并且与租户提供支持的产品相关联。支持代理（支持客服）只能在他们的工作时间处理工单，工作时间这是由他们的轮班时间表定义的。
4. Consider a software project you are working on at the moment or worked on in the past: 思考一个你现在正在做的或者过去做过的软件项目:
a. Try to come up with concepts of the business domain that you could use in conversations with domain experts. 尝试提出业务领域的概念，您可以在与领域专家的对话中使用这些概念。
b. Try to identify examples of inconsistent terms: business domain concepts that have either different meanings or identical concepts represented by different terms. 尝试识别不一致术语的示例: 业务领域概念具有不同的含义，或者由不同术语表示的相同概念。
c. Have you encountered software development inefficiencies that resulted from poor communication? 您是否遇到过由于缺乏沟通而导致的软件开发效率低下的情况？
5. Assume you are working on a project and you notice that domain experts from different organizational units use the same term, for example, policy, to describe unrelated concepts of the business domain.
假设您正在从事一个项目，并注意到来自不同组织单位的领域专家使用相同的术语（例如policy）来描述业务领域中不相关的概念。
The resultant ubiquitous language is based on domain experts’ mental models but fails to fulfill the requirement of a term having a single meaning.
由此产生的通用语言是基于领域专家的心智模型，但不能满足一个术语具有单一意义的要求。
Before you continue to the next chapter, how would you address such a conundrum?
在你继续下一章之前，你将如何解决这样一个难题？
1 Brandolini, Alberto. (n.d.). Introducing EventStorming（事件风暴）. Leanpub.
2 Sudhakar, Goparaju Purna. (2012). “A Model of Critical Success Factors for Software Projects.” Journal of Enterprise Information Management, 25(6), 537–558.
3 Players form a line, and the first player comes up with a message and whispers it into the ear of the second player. The second player repeats the message to the third player, and so on. The last player announces the message they heard to the entire group. The first player then compares the original message with the final version. Although the objective is to communicate the same message, it usually gets garbled and the last player receives a message that is significantly different from the original one.
玩家排成一行，第一个玩家拿出一条消息，对第二个玩家耳语。第二个玩家向第三个玩家重复消息，以此类推。最后一个玩家向整个团队宣布他们听到的消息。然后，第一个播放器将原始信息与最终版本进行比较。尽管目标是传递相同的信息，但是它通常会被篡改，最后一个玩家会收到一条与原始信息明显不同的信息。
4 Edsger W. Dijkstra, “The Humble Programmer”. 谦卑的程序员
5 But please don’t fall into the trap of thinking that domain experts will write Gherkin tests. 但是，请不要陷入这样的思维陷阱，即领域专家将编写Gherkin 测试
