烂翻译系列之学习领域驱动设计——第四章：集成有界上下文

Not only does the bounded context pattern protect the consistency of a ubiquitous language, it also enables modeling. You cannot build a model without specifying its purpose—its boundary. The boundary divides the responsibility of languages. A language in one bounded context can model the business domain to solve a particular problem. Another bounded context can represent the same business entities but model them to solve a different problem.

有界上下文模式不仅保护了通用语言的一致性，它还使建模成为可能。如果没有指定模型的目的——即其边界，就无法构建模型。边界划分了语言的责任。一个有界上下文中的语言可以为业务域建模以解决特定的问题。另一个有界上下文可以表示相同的业务实体，但对它们进行建模以解决不同的问题。

Moreover, models in different bounded contexts can be evolved and implemented independently. That said, bounded contexts themselves are not independent. Just as a system cannot be built out of independent components—the components have to interact with one another to achieve the system’s overarching goals—so, too, do the implementations in bounded contexts. Although they can evolve independently, they have to integrate with one another. As a result, there will always be touchpoints between bounded contexts. These are called contracts.

此外，不同有界上下文中的模型可以独立地进化和实现。也就是说，有界上下文本身并不是独立的。正如一个系统不能由独立的组件构建而成一样（这些组件必须相互交互以实现系统的总体目标），有界上下文中的实现也是如此。虽然它们可以独立进化，但它们必须相互集成。因此，在有界上下文之间总是存在接触点。这些接触点被称为契约。

The need for contracts results from differences in bounded contexts’ models and languages. Since each contract affects more than one party, they need to be defined and coordinated. Also, by definition, two bounded contexts are using different ubiquitous languages. Which language will be used for integration purposes? These integration concerns should be evaluated and addressed by the solution’s design.

由于有界上下文之间在模型和语言上的差异，产生了对契约的需求。由于每个契约都涉及多个参与方，因此需要定义和协调这些契约。同样地，根据定义，两个不同的有界上下文使用不同的通用语言。那么，将使用哪种通用语言来进行集成？这些集成问题应该由解决方案的设计进行评估和解决。

In this chapter, you will learn about domain-driven design patterns for defining relationships and integrations between bounded contexts. These patterns are driven by the nature of collaboration between teams working on bounded contexts. We will divide the patterns into three groups, each representing a type of team collaboration: cooperation, customer–supplier, and separate ways.

在本章中，您将学习用于定义有界上下文之间关系和集成的领域驱动设计模式。这些模式由在有界上下文上工作的团队之间的协作性质所驱动。我们将这些模式分为三组，每组代表一种团队协作类型：合作、客户-供应商和分离（各行其道）方式。

Cooperation

合作

Cooperation patterns relate to bounded contexts implemented by teams with well-established communication.

合作模式涉及由沟通顺畅的团队实现的有界上下文。

In the simplest case, these are bounded contexts implemented by a single team. This also applies to teams with dependent goals, where one team’s success depends on the success of the other, and vice versa. Again, the main criterion here is the quality of the teams’ communication and collaboration.

在最简单的情况下，这些是由单个团队实现的有界上下文。这也适用于目标相互依赖的团队，其中一个团队的成功取决于另一个团队的成功，反之亦然。同样，这里的主要标准是团队之间的沟通和协作质量。

Let’s look at two DDD patterns suitable for cooperating teams: the partnership and shared kernel patterns.

让我们来看看两种适合合作团队的DDD（领域驱动设计）模式：合作伙伴关系和共享内核模式。

Partnership

合作伙伴关系

In the partnership model, the integration between bounded contexts is coordinated in an ad hoc manner. One team can notify a second team about a change in the API, and the second team will cooperate and adapt—no drama or conflicts (see Figure 4-1).

在合作伙伴关系模式中，有界上下文之间的集成以一种特别的方式进行协调。一个团队可以通知第二个团队 API 的更改，一个团队可以通知第二个团队关于API的变更，而第二个团队将进行配合和适配——没有戏剧性或冲突(参见图4-1)。

 

Figure 4-1. The partnership model

图4-1.  合作伙伴关系模式

The coordination of integration here is two-way. No one team dictates the language that is used for defining the contracts. The teams can work out the differences and choose the most appropriate solution. Also, both sides cooperate in solving any integration issues that might come up. Neither team is interested in blocking the other one.

这里的集成协调是双向的。没有哪个团队会强制规定用于定义契约的语言。团队间可以解决分歧并选择最合适的解决方案。同时，双方也会合作解决可能出现的任何集成问题。任何一方都没有兴趣阻碍对方。

Well-established collaboration practices, high levels of commitment, and frequent synchronizations between teams are required for successful integration in this manner. From a technical perspective, continuous integration of the changes applied by both teams is needed to further minimize the integration feedback loop.

以这种方式成功地集成需要建立良好的协作实践、高度的承诺以及团队之间的频繁同步。从技术角度来看，需要对两个团队应用的变更进行持续集成，以进一步缩短集成反馈循环。

This pattern might not be a good fit for geographically distributed teams since it may present synchronization and communication challenges.

这种模式可能不适合地理上分散的团队，因为它可能会带来同步和沟通方面的挑战。

Shared Kernel

共享内核

Despite bounded contexts being model boundaries, there still can be cases when the same model of a subdomain, or a part of it, will be implemented in multiple bounded contexts. It’s crucial to stress that the shared model is designed according to the needs of all of the bounded contexts. Moreover, the shared model has to be consistent across all of the bounded contexts that are using it.

尽管有界上下文是模型的边界，但仍然可能存在这样的情况：子域或其一部分的相同模型将在多个有界上下文中实现。必须强调的是，共享模型是根据所有有界上下文的需求来设计的。此外，共享模型必须在所有使用它的有界上下文中保持一致。

As an example, consider an enterprise system that uses a tailor-made model for managing users’ permissions. Each user can have their permissions granted directly or inherited from one of the organizational units they belong to. Moreover, each bounded context can modify the authorization model, and the changes each bounded context applies have to affect all the other bounded contexts using the model (see Figure 4-2).

例如，思考一个企业系统，该系统使用定制的模型来管理用户的权限。每个用户可以直接获得权限，也可以从他们所属的组织单位之一继承权限。此外，每个有界上下文都可以修改授权模型，每个有界上下文所做的更改必然影响使用该模型的所有其他有界上下文（参见图4-2）。

 

Figure 4-2. Shared kernel

图4-2. 共享内核

Shared scope

共享范围

The overlapping model couples the lifecycles of the participating bounded contexts. A change made to the shared model has an immediate effect on all the bounded contexts. Hence, to minimize the cascading effects of changes, the overlapping model should be limited, exposing only that part of the model that has to be implemented by both bounded contexts. Ideally, the shared kernel will consist only of integration contracts and data structures that are intended to be passed across the bounded contexts’ boundaries.

重叠模型将所涉及的所有有界上下文的生命周期耦合在一起。对共享模型所做的更改会立即影响到所有有界上下文。因此，为了最大限度地减少更改的连锁效应，重叠模型应该受到限制，只暴露那些两个有界上下文都必须实现的模型部分。理想情况下，共享内核将仅包含旨在跨越有界上下文边界传递的集成契约和数据结构。

Implementation

实现

The shared kernel is implemented so that any modification to its source code is immediately reflected in all the bounded contexts using it.

共享内核的实现方式是，对其源代码的任何修改都会立即反映在使用它的所有有界上下文中。

If the organization uses the mono-repository approach, these can be the same source files referenced by multiple bounded contexts. If using a shared repository is not possible, the shared kernel can be extracted into a dedicated project and referenced in the bounded contexts as a linked library. Either way, each change to the shared kernel must trigger integration tests for all the affected bounded contexts.

如果组织采用单一代码库方法，这些可能是由多个有界上下文引用的相同源文件。如果不能使用共享代码库，则可以将共享内核提取到一个专用项目中，并在有界上下文中作为链接库进行引用。无论哪种方式，对共享内核的每次更改都必须触发所有受影响的有界上下文的集成测试。

The continuous integration of changes is required because the shared kernel belongs to multiple bounded contexts. Not propagating shared kernel changes to all related bounded contexts leads to inconsistencies in a model: bounded contexts may rely on stale implementations of the shared kernel, leading to data corruption and/or runtime issues.

由于共享内核属于多个有界上下文，因此需要对更改进行持续集成。如果不将共享内核的更改传播到所有相关的有界上下文，就会导致模型中的不一致性: 有界上下文可能依赖于共享内核的旧（过时）实现，从而导致数据损坏和/或运行时问题。

When to use shared kernel

何时使用共享内核

The overarching applicability criterion for the shared kernel pattern is the cost of duplication versus the cost of coordination. Since the pattern introduces a strong dependency between the participating bounded contexts, it should be applied only when the cost of duplication is higher than the cost of coordination—in other words, only when integrating changes applied to the shared model by both bounded contexts will require more effort than coordinating the changes in the shared codebase.

共享内核模式的总体适用性标准是重复的成本与协调的成本之间的比较。由于该模式在涉及的有界上下文之间引入了强依赖性，因此只有当重复的成本高于协调的成本时才应用该模式——换句话说，只有当两个有界上下文都对共享模型所做的变更进行集成时，比协调共享代码库中的变更需要更多的努力时才应用该模式。

The difference between the integration and duplication costs depends on the volatility of the model. The more frequently it changes, the higher the integration costs will be. Therefore, the shared kernel will naturally be applied for the subdomains that change the most: the core subdomains.

集成成本和重复成本之间的差异取决于模型的变动性。它变化得越频繁，集成成本就会越高。因此，共享内核将自然地应用于变化最大的子域: 核心子域。

In a sense, the shared kernel pattern contradicts the principles of bounded contexts introduced in the previous chapter. If the participating bounded contexts are not implemented by the same team, introducing a shared kernel contradicts the principle that a single team should own a bounded context. The overlapping model—the shared kernel—is, in effect, being developed by multiple teams.

在某种意义上，共享内核模式与前一章介绍的有界上下文原则相矛盾。如果参与的有界上下文不是由同一个团队实现的，那么引入共享内核就违背了单个团队应该拥有有界上下文的原则。实际上，重叠模型（即共享内核）是由多个团队开发的。

That’s the reason why the use of a shared kernel has to be justified. It’s a pragmatic exception that should be considered carefully. A common use case for implementing a shared kernel is when communication or collaboration issues prevent implementing the partnership pattern—for example, because of geographical constraints or organizational politics. Implementing a closely related functionality without proper coordination will result in integration issues, desynchronized models, and arguments about which model is better designed. Minimizing the shared kernel’s scope controls the scope of cascading changes, and triggering integration tests for each change is a way to enforce early detection of integration issues.

这就是为什么使用共享内核必须得到合理的解释。这是一个实用的例外，应该仔细考虑。实现共享内核的一个常见用例是，当沟通或协作问题阻碍了实现合作伙伴模式时——例如，由于地理限制或组织政治壁垒。在没有适当协调的情况下实现紧密相关的功能将导致集成问题、模型不同步以及关于哪个模型设计得更好的争论。最小化共享内核的范围可以控制级联更改的范围，而对每次更改触发集成测试是及早发现集成问题的一种方式。

Another common use case for applying the shared kernel pattern, albeit a temporary one, is the gradual modernization of a legacy system. In such a scenario, the shared codebase can be a pragmatic intermediate solution for gradually decomposing the system into bounded contexts.

应用共享内核模式的另一个常见用例（尽管是临时的）是逐步现代化遗留系统。在这种情况下，共享代码库可以作为一个实用的中间解决方案，用于逐步将系统分解为有界上下文。

Finally, a shared kernel can be a good fit for integrating bounded contexts owned and implemented by the same team. In such a case, an ad hoc integration of the bounded contexts—a partnership—can “wash out” the contexts’ boundaries over time. A shared kernel can be used for explicitly defining the bounded contexts’ integration contracts.

最后，共享内核非常适合集成由同一个团队拥有和实现的有界上下文。在这种情况下，有界上下文的特定集成（即合作伙伴关系）可能随着时间的推移而“模糊”上下文的边界。共享内核可以用于明确定义有界上下文的集成契约。

Customer–Supplier

客户——供应商

The second group of collaboration patterns we’ll examine is the customer– supplier patterns. As shown in Figure 4-3, one of the bounded contexts— the supplier—provides a service for its customers. The service provider is “upstream” and the customer or consumer is “downstream.”

我们将研究的第二组协作模式是客户-供应商模式。如图4-3所示，其中一个有界上下文（即供应商）为其客户提供服务。服务提供商是“上游”，而客户或消费者是“下游”。

 

Figure 4-3. Customer–supplier relationship

图4-3.  客户-供应商关系

Unlike in the cooperation case, both teams (upstream and downstream) can succeed independently. Consequently, in most cases we have an imbalance of power: either the upstream or the downstream team can dictate the integration contract.

与合作情况不同，两个团队（上游和下游）都可以独立成功。因此，在大多数情况下，我们存在权力不平衡：要么是上游团队，要么是下游团队可以决定集成契约。

This section will discuss three patterns addressing such power differences: the conformist, anticorruption layer, and open-host service patterns.

本节将讨论三种针对这种权力差异的模式：遵奉模式、防腐层模式和开放主机服务模式。

Conformist

遵奉

In some cases, the balance of power favors the upstream team, which has no real motivation to support its clients’ needs. Instead, it just provides the integration contract, defined according to its own model—take it or leave it. Such power imbalances can be caused by integration with service providers that are external to the organization or simply by organizational politics.

在某些情况下，权力平衡偏向上游团队，而上游团队没有真正的动力去支持其客户的需求。相反，它只是根据自身的模型定义了集成契约——要么接受，要么放弃。这种权力不平衡可能是由于与组织外部的服务提供商进行集成或仅仅是组织内部政治造成的。

If the downstream team can accept the upstream team’s model, the bounded contexts’ relationship is called conformist. The downstream conforms to the upstream bounded context’s model, as shown in Figure 4-4.

如果下游团队可以接受上游团队的模型，那么有界上下文之间的关系就被称为遵奉关系。如图4-4所示，下游团队遵循上游有界上下文的模型。

 

Figure 4-4. Conformist relationship

图4-4.  遵奉关系

The downstream team’s decision to give up some of its autonomy can be justified in multiple ways. For example, the contract exposed by the upstream team may be an industry-standard, well-established model, or it may just be good enough for the downstream team’s needs.

下游团队放弃部分自主权的决定可以有多种理由。例如，上游团队公开的契约可能是一个行业标准，一个成熟的模型，或者它可能只是满足下游团队需求的足够好的选择。

The next pattern addresses the case in which a consumer is not willing to accept the supplier’s model.

下一个模式解决了客户不愿意接受供应商模型的情况。

Anticorruption Layer

防腐层

As in the conformist pattern, the balance of power in this relationship is still skewed toward the upstream service. However, in this case, the downstream bounded context is not willing to conform. Instead, it can translate the upstream bounded context’s model into a model tailored to its own needs via an anticorruption layer, as shown in Figure 4-5.

正如在遵奉者模式中一样，这种关系中的权力平衡仍然向上游服务倾斜。但是，在这种情况下，下游有界上下文不愿意遵从。相反，它可以通过防腐层将上游有界上下文的模型转换为适合其自身需要的模型，如图4-5所示。

翻译：与顺应者模式一样，这种关系中的权力平衡仍然偏向上游服务。然而，在这种情况下，下游有界上下文不愿意顺应。相反，它可以通过一个防腐层将上游有界上下文的模型转换为一个符合自身需求的模型，如图4-5所示。 

 

Figure 4-5. Integration through an anticorruption layer

图4-5.  通过防腐层的集成

The anticorruption layer pattern addresses scenarios in which it is not desirable or worth the effort to conform to the supplier’s model, such as the following:

防腐层模式针对的是不希望或不值得努力尝试遵从供应商模型的情况，例如:

When the downstream bounded context contains a core subdomain  当下游有界上下文包含一个核心子域时 

       A core subdomain’s model requires extra attention, and adhering to the supplier’s model might impede the modeling of the problem domain.  核心子域的模型需要格外的关注，并且遵从供应商的模型可能会阻碍问题领域的建模。

When the upstream model is inefficient or inconvenient for the consumer’s needs  当上游模式效率低下或不便于满足客户需求时 

       If a bounded context conforms to a mess, it risks becoming a mess itself. That is often the case when integrating with legacy systems.  如果一个有界上下文遵从一泥球（混乱状态），那么它本身就有可能变成一泥球。与遗留系统集成时通常会出现这种情况。

When the supplier’s contract changes often  当供应商的契约经常变更时 

       The consumer wants to protect its model from frequent changes. With an anticorruption layer, the changes in the supplier’s model only affect the translation mechanism.  客户希望保护其模型免受频繁更改的影响。有了防腐层（anticorruption layer），供应商模型中的变更只影响转换机制。

From a modeling perspective, the translation of the supplier’s model isolates the downstream consumer from foreign concepts that are not relevant to its bounded context. Hence, it simplifies the consumer’s ubiquitous language and model.

从建模的角度来看，对供应商模型的转换将下游客户与其限界上下文不相关的外部概念隔离开来。因此，它简化了客户的通用语言和模型。

In Chapter 9, we will explore the different ways to implement an anticorruption layer.

在第9章中，我们将探讨实现防腐层的不同方式。

Open-Host Service

开放主机服务

This pattern addresses cases in which the power is skewed toward the consumers. The supplier is interested in protecting its consumers and providing the best service possible.

这个模式针对的是权力偏向客户的情况。供应商关注保护其客户并提供尽可能最好的服务。

To protect the consumers from changes in its implementation model, the upstream supplier decouples the implementation model from the public interface. This decoupling allows the supplier to evolve its implementation and public models at different rates, as shown in Figure 4-6.

为了保护客户免受上游供应商的实现模型变更的影响，上游供应商将实现模型与公共接口分离（解耦）。这种分离允许供应商以不同的速度发展其实现模型和公共模型，如图4-6所示。

  

Figure 4-6. Integration through an open-host service

图4-6.  通过开放主机服务进行集成

The supplier’s public interface is not intended to conform to its ubiquitous language. Instead, it is intended to expose a protocol convenient for the consumers, expressed in an integration-oriented language. As such, the public protocol is called the published language.

供应商的公共接口并不是为了遵循其通用语言。相反，它旨在公开一个方便客户的协议，该协议以面向集成的语言来表达。因此，公共协议被称为发布语言（published language）。

In a sense, the open-host service pattern is a reversal of the anticorruption layer pattern: instead of the consumer, the supplier implements the translation of its internal model.

从某种意义上说，开放主机服务模式是防腐层模式的反转: 供应商实现其内部模型的转换（翻译），而不是客户。

Decoupling the bounded context’s implementation and integration models gives the upstream bounded context the freedom to evolve its implementation without affecting the downstream contexts. Of course, that’s only possible if the modified implementation model can be translated into the published language the consumers are already using.

将有界上下文的实现模型和集成模型解耦，使得上游限界上下文可以自由地演化其实现而不影响下游上下文。当然，这只有在修改后的实现模型可以被转换成客户已经使用的发布语言时才是可能的。

Furthermore, the integration model’s decoupling allows the upstream bounded context to simultaneously expose multiple versions of the published language, allowing the consumer to migrate to the new version gradually (see Figure 4-7).

此外，集成模型的解耦使得上游限界上下文能够同时公开（暴露）发布语言的多个版本，允许客户逐步迁移到新版本（见图4-7）。

 

Figure 4-7. Open-host service exposing multiple versions of the published language

图4-7.  开放主机服务公开发布语言的多个版本

Separate Ways

分离（各行其道、各自为政）

The last collaboration option is not to collaborate at all. This pattern can arise for different reasons, in cases where the teams are unwilling or unable to collaborate. We’ll look at a few of them here.

最后一个协作选项是完全不协作。这种模式可能由于不同的原因产生，比如团队不愿意或无法协作。我们在这里将探讨其中的几个原因。

Communication Issues

沟通问题

A common reason for avoiding collaboration is communication difficulties driven by the organization’s size or internal politics. When teams have a hard time collaborating and agreeing, it may be more cost-effective to go their separate ways and duplicate functionality in multiple bounded contexts.

阻碍协作的一个常见原因是由组织规模或内部政治导致的沟通困难。当团队在协作和达成一致意见上遇到困难时，它们各自为政、在多个限界上下文中重复功能可能更具成本效益。

Generic Subdomains

通用子域

The nature of the duplicated subdomain can also be a reason for teams to go their separate ways. When the subdomain in question is generic, and if the generic solution is easy to integrate, it may be more cost-effective to integrate it locally in each bounded context. An example is a logging framework; it would make little sense for one of the bounded contexts to expose it as a service. The added complexity of integrating such a solution would outweigh the benefit of not duplicating the functionality in multiple contexts. Duplicating the functionality would be less expensive than collaborating.

重复子域的性质也可能是团队各行其道的一个原因。当相关子域是通用的，并且通用解决方案易于集成时，在每个限界上下文中本地集成它可能更具成本效益。例如，日志记录框架就是一个例子；让一个有界上下文将其作为服务公开是没有多大意义的。集成此类解决方案的额外复杂性将超过不在多个上下文中重复功能的好处。与协作相比，重复功能的成本更低。

Model Differences

模型差异

Differences in the bounded contexts’ models can also be a reason to go with a separate ways collaboration. The models may be so different that a conformist relationship is impossible, and implementing an anticorruption layer would be more expensive than duplicating the functionality. In such a case, it is again more cost-effective for the teams to go their separate ways.

翻译：有界上下文模型之间的差异也可能是选采用分离（各行其道）方式协作方式的原因。这些模型可能差异如此之大，以至于不可能建立一种遵从关系，而且实现一个防腐层将比复制功能代价更加昂贵。在这种情况下，团队再次选择各行其道是更具成本效益的。

---

NOTE  备注

The separate ways pattern should be avoided when integrating core subdomains. Duplicating the implementation of such subdomains would defy the company’s strategy to implement them in the most effective and optimized way.

在集成核心子域时应避免分离方式模式。重复实施这些子域将违背公司的战略，应以最有效和最优化的方式实施它们。

---

Context Map

上下文映射

After analyzing the integration patterns between a system’s bounded contexts, we can plot them on a context map, as shown in Figure 4-8.

在分析完系统限界上下文之间的集成模式后，我们可以在上下文映射（context map）上绘制它们，如图4-8所示。

 

Figure 4-8. Context map

图4-8.  上下文映射

The context map is a visual representation of the system’s bounded contexts and the integrations between them. This visual notation gives valuable strategic insight on multiple levels:

上下文映射是系统的有界上下文以及它们之间的集成的可视化表示。这种可视化表示法在多个层面上提供了有价值的战略见解:

High-level design  高层设计

       A context map provides an overview of the system’s components and the models they implement.  上下文映射提供了系统组件及其实现的模型的概览。

Communication patterns  沟通模式

       A context map depicts the communication patterns among teams—for example, which teams are collaborating and which prefer “less intimate” integration patterns, such as the anticorruption layer and separate ways patterns.    上下文映射描绘了团队之间的通信模式——例如，哪些团队正在协作，哪些团队更喜欢“不那么亲密”的集成模式，如防腐层和分离（各行其道）模式。

Organizational issues  组织问题

       A context map can give insight into organizational issues. For example, what does it mean if a certain upstream team’s downstream consumers all resort to implementing an anticorruption layer, or if all implementations of the separate ways pattern are concentrated around the same team?上下文映射可以提供对组织问题的深入了解。例如，如果某个上游团队的下游消费者都采取实现防腐层，或者如果所有分离方式模式的实现都集中在同一个团队周围，这意味着什么？

Maintenance

维护

Ideally, a context map should be introduced into a project right from the get-go, and be updated to reflect additions of new bounded contexts and modifications to the existing one.

理想情况下，应该从一开始就将上下文映射引入到项目中，并随着新有界上下文的添加和现有限界上下文的修改而更新它。

Since the context map potentially contains information originating from the work of multiple teams, it’s best to define the maintenance of the context map as a shared effort: each team is responsible for updating its own integrations with other bounded contexts.

由于上下文映射可能包含来自多个团队工作的信息，因此最好将上下文映射的维护定义为一项共同的努力：每个团队都负责更新自己与其他有界上下文之间的集成。

A context map can be managed and maintained as code, using a tool like Context Mapper.

可以使用像Context Mapper这样的工具将上下文映射作为代码来管理和维护。

Limitations

缺点

It’s important to note that charting a context map can be a challenging task. When a system’s bounded contexts encompass multiple subdomains, there can be multiple integration patterns at play. For example, in Figure 4-9, you can see two bounded contexts with two integration patterns: partnership and anticorruption layer.

值得注意的是，绘制上下文映射可能是一项具有挑战性的任务。当系统的有界上下文包含多个子域时，可能会有多种集成模式在起作用。例如，在图4-9中，您可以看到两个限界上下文与两种集成模式：合作伙伴关系和防腐层。

Figure 4-9. Complicated context map

图4-9. 复杂的上下文映射

Moreover, even if bounded contexts are limited to a single subdomain, there still can be multiple integration patterns at play—for example, if the subdomains’ modules require different integration strategies.

此外，即使有界上下文仅限于单个子域，也可能有多种集成模式在起作用——例如，如果子域的模块需要不同的集成策略。

Conclusion

总结

Bounded contexts are not independent. They have to interact with one another. The following patterns define different ways bounded contexts can be integrated:

有界上下文不是孤立的。他们必须互相作用。以下模式定义了集成有界上下文的不同方式：

Partnership  合作关系

       Bounded contexts are integrated in an ad hoc manner.  有界上下文以特定方式集成。

Shared kernel  共享内核

       Two or more bounded contexts are integrated by sharing a limited overlapping model that belongs to all participating bounded contexts.  两个或多个限界上下文通过共享一个属于所有参与（涉及的）限界上下文的有限重叠模型来进行集成。

Conformist  遵奉者

       The consumer conforms to the service provider’s model.  消费者遵从服务提供者的模型。    翻译：消费者遵循服务提供商的模型。

Anticorruption layer  防腐层

       The consumer translates the service provider’s model into a model that fits the consumer’s needs.  消费者将服务提供者的模型转换为适合消费者需要的模型。    翻译：消费者将服务提供商的模型转换为符合消费者需求的模型。

Open-host service  开放主机服务

       The service provider implements a published language—a model optimized for its consumers’ needs.  服务提供商实现了一种发布语言——一种针对客户需求进行优化的模型。

Separate ways  分离方式

       It’s less expensive to duplicate particular functionality than to collaborate and integrate it.  与协作和集成相比，复制特定功能的成本更低。   

The integrations among the bounded contexts can be plotted on a context map. This tool gives insight into the system’s high-level design, communication patterns, and organizational issues.

限界上下文之间的集成可以在上下文映射上绘制。这个工具提供了对系统高层设计、通信模式和组织问题的深入了解。

Now that you have learned about the domain-driven design tools and techniques for analyzing and modeling business domains, we will shift our perspective from strategy to tactics. In Part II, you’ll learn different ways to implement domain logic, organize high-level architecture, and coordinate communication between a system’s components.

现在您已经了解了用于分析和建模业务领域的领域驱动设计工具和技术，我们将从战略视角转向战术视角。在第二部分中，您将学习实现领域逻辑、组织高层架构以及协调系统组件之间通信的不同方法。

Exercises

练习

1. Which integration pattern should never be used for a core subdomain?  核心子域永远不应该使用哪种集成模式？

a. Shared kernel  共享内核

b. Open-host service  开放主机服务

c. Anticorruption layer  防腐层

d. Separate ways  分离方式

答案：d。The pattern entails duplicate implementation of a functionality in multiple bounded contexts. Duplicating complex, volatile, and business-critical business logic should be avoided at all costs.    这个模式需要在多个有界上下文中重复实现某个功能。应不惜一切代价避免重复实现复杂、易变和业务关键的业务逻辑。

2. Which downstream subdomain is more likely to implement an anticorruption layer?  哪个下游子域更有可能实现防腐层？

a. Core subdomain  核心子域

b. Supporting subdomain  支撑子域

c. Generic subdomain  通用子域

d. B and C  支撑子域和通用子域

答案：A。A core subdomain is most likely to leverage an anticorruption layer to protect itself from ineffective models exposed by upstream services, or to contain frequent changes in the upstream’s public interfaces.    核心子域最有可能利用防腐层来保护自己免受上游服务暴露的无效模型的影响，或者包含上游公共接口的频繁更改。

3. Which upstream subdomain is more likely to implement an open-host service?  哪个上游子域更有可能实现开放主机服务？

a. Core subdomain  核心子域

b. Supporting subdomain  支撑子域

c. Generic subdomain  通用子域

d. A and B  核心子域和支撑子域

答案：A。A core subdomain is most likely to implement the open-host service. Decoupling its implementation model from the public interface (published language) makes it more convenient to evolve the core subdomain’s model without affecting its downstream consumers.    核心子域最有可能实现开放主机服务。将其实现模型与公共接口（发布语言）解耦，可以更方便地演化核心子域的模型，而不会影响其下游客户。

4. Which integration pattern, in a sense, violates bounded contexts’ ownership boundaries?  哪种集成模式在某种意义上违反了有界上下文的所有权边界？

a. Partnership.  合作关系

b. Shared kernel.  共享内核

c. Separate ways.  分离方式

d. No integration pattern should ever break the bounded contexts’ ownership boundaries.  任何集成模式都不应该打破有界上下文的所有权边界。

答案：b。The shared kernel pattern is an exception to the bounded contexts’ single team ownership rule. It defines a small portion of the model that is shared and can be evolved simultaneously by multiple bounded contexts. The shared part of the model should be always kept as small as possible.    共享内核模式（Shared Kernel pattern）是有界上下文单一团队所有权规则的例外。它定义了模型的一小部分，这部分是共享的，可以由多个有界上下文同时演化。模型的共享部分应该始终保持尽可能小。