烂翻译系列之学习领域驱动设计——第二章：发现领域知识

It’s developers’ (mis)understanding, not domain experts’ knowledge, that gets released in production. —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.

业务问题既出现在业务领域层面，也出现在子域层面。公司的目标是为其客户的问题提供解决方案。回到第一章的FedEx（联邦快递）例子，该公司的客户需要在有限的时间内寄送包裹，因此它优化了运输流程。

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.

为了设计一个有效的软件解决方案，我们至少需要掌握业务领域的基本知识。正如我们在第一章中讨论的那样，这些知识属于领域专家：他们的工作是专门研究和理解业务领域的所有复杂性。我们绝不应该，也不能成为领域专家。但话说回来，理解领域专家并使用他们所使用的相同的业务术语对我们至关重要。

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.

与不断翻译领域知识相反，领域驱动设计提倡培养一种用于描述业务领域的单一语言：通用语言（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.

通用语言要求每个术语具有单一含义，因此应该使用“regulatory rule”（监管规则）和“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”（用户）和其他术语（如 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.

从本质上讲，模型是一种抽象。抽象的概念使我们能够通过省略不必要的细节并仅保留解决手头问题所需的内容来处理复杂性。另一方面，无效的抽象会删除必要的信息或产生不必要的噪音。正如埃德加·W·狄克斯特拉（Edsger W. Dijkstra）在他的论文《谦卑的程序员》中所指出的那样，抽象的目的不是含糊不清，而是创建一个新的语义层面，在这个层面上人们可以绝对精确。

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.

我们使用的通用语言不应该涵盖领域的每一个可能的细节。这相当于让每个利益相关者都成为领域专家。相反，模型应该只包含足够的业务领域方面，以便实现所需的四个系统；也就是说，解决软件旨在解决的特定问题。在后续章节中，您将看到通用语言是如何驱动底层设计和实现决策的。

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）实践时，你会注意到已经有一种用于描述业务领域的语言，并且利益相关者正在使用它。然而，由于这种语言并不由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 测试等工具可以极大地减轻编写文档和维护通用语言的过程。然而，有效的通用语言的主要先决条件是使用：该语言必须在所有与项目相关的沟通中得到一致的使用。

基于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.    Sudhakar, Goparaju Purna. (2012). “软件项目的关键成功因素模型。” 《企业信息管理杂志》，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 测试