领域驱动设计中的边界上下文集成

领域驱动设计（DDD）自2003年由Eric Evans引入以来，已成为软件开发中一种重要的方法论。本文将重点探讨边界上下文的集成问题，并简要介绍领域驱动设计中的一些基本概念。

无处不在的语言

在DDD中，语言是一个核心概念。它要求我们建立一种清晰、一致的语言，以促进领域专家和开发人员之间的有效沟通。以下是语言在DDD中的重要性：

精确性：所有概念，无论是否在代码中体现，都应有明确的定义，避免混淆。- 一致性：语言的使用应保持一致，以减少误解。例如，系统使用者可能被称为“用户”，而领域专家可能更倾向于使用“客户”这一术语。这种差异可能会导致沟通上的混淆。

语言的力量

正确的语言使用可以帮助我们明确概念，避免在业务需求转化为实现时出现意图的丢失。例如，将“运输信息”明确定义为“目的地地址”。

语言的范围

在编程中，范围指的是变量等识别项的可见性区域。类似地，在DDD中，我们认识到语言的有效性是有限的，它适用于特定的上下文。

设定界限：边界上下文

边界上下文（BC）是DDD中的一个关键概念，它帮助我们理解模型和语言的适用范围。以下是边界上下文的要点：

定义：明确定义模型应用的上下文，包括团队组织、应用程序的特定部分以及物理表现形式。- 一致性：在边界上下文中保持模型的严格一致性，避免外部因素的干扰。 Eric Evans强调，我们应该明确设置边界，并在这些边界内保持模型的一致性，同时不被外部问题所分散。

边界上下文的集成

在多个边界上下文之间集成时，我们需要考虑如何保持模型的一致性，同时允许不同上下文之间的差异。这涉及到对不同上下文的深入理解和有效的沟通策略。

结语

本文简要介绍了领域驱动设计中的边界上下文集成问题，并强调了语言在其中的重要性。通过正确使用语言和理解边界上下文，我们可以更有效地进行软件开发，满足复杂的业务需求。请继续关注后续文章，我们将深入探讨聚合设计等其他DDD主题。

图 1: 不同边界上下文及其关系解析

边界上下文间的关系

边界上下文是领域驱动设计中的一个重要概念，用于划分具有明确界限的业务领域。在图 1 中，我们观察到边界上下文之间可能存在或不存在关系。以下是对这些关系的详细分析：

独立边界上下文

无关系：某些边界上下文可能完全独立，它们之间没有直接的联系。在这种情况下，即使在这些边界上下文中出现相同的模型名称，它们的定义和用途也可能完全不同。这种命名的一致性可能是经过深思熟虑的决策，以避免混淆。

共享关系的边界上下文

相同名称，不同定义：在某些情况下，不同的边界上下文可能使用相同的模型名称，但这些模型在不同上下文中有着不同的定义和用途。- 不同名称，共享特征：另一方面，不同边界上下文的模型可能有不同的名称，但它们之间共享一些或全部的共同特征。

上下文映射

对于存在共享关系的边界上下文，上下文映射是一种重要的工具，它提供了关于这些上下文之间关系如何影响它们的模型和语言的详细信息。上下文映射帮助我们理解：

模型的演变：在不同的边界上下文中，模型是如何演化和适应各自需求的。- 语言的协调：如何确保在不同上下文中使用的语言保持一致性，避免歧义。

结论

边界上下文及其关系的理解对于设计一个清晰、可维护的系统至关重要。通过分析边界上下文间的独立性和共享性，我们可以更好地组织业务逻辑，确保系统的灵活性和可扩展性。

图2.上游/下游关系。

在这里，上游是决定关系的人，使下游将语言作为他们自己的一部分。在我们的示例中，不仅在代码中使用了 Customer Profile，而且还被识别为 Checkout Bounded Context 的概念部分。

反腐败层

图3：具有反腐败层的上游/下游概念实现

概述在本示例中，我们将探讨如何在不依赖产品信息管理（PIM）系统的情况下，定义和实现本地概念模型，以及如何通过集成实现上游/下游关系。

连接点的实现### 1. 定义本地概念首先，我们定义一个名为“订购偏好”的本地概念模型。此模型由结账流程使用，用于了解客户的预定义交付偏好。

2. 应用程序服务集成我们的应用程序服务（命令处理程序）需要获取客户的订购偏好，以创建符合业务规则的结账流程。

3. 接口表示_OrderingPreferences_ 作为一个本地概念，可以通过一个接口来表示。这允许我们将其与客户配置文件解耦，并通过服务进行集成。

4. 基础设施层实现在基础设施层，我们实现了一个与客户配置文件交互的接口，以生成所需的值对象。

5. 使用HTTP客户端通过HTTP客户端，我们从客户配置文件中检索数据，并使用这些数据创建_OrderingPreferences_。

构建本地概念### 1. 仓库业务需求我们的仓库业务需要提供一些监管信息，用于处理和运送客户订单。

2. 外部定义的集成这些监管信息位于PIM系统的边界上下文中，作为产品模型的一部分。

3. 构建本地概念我们不是直接导入这些概念，而是根据PIM中的外部定义构建本地概念，以满足我们的业务需求。

结论通过上述实现，我们展示了如何在不同的上下文中定义和使用本地概念，以及如何通过集成实现上游/下游关系。这种方法有助于保持系统的灵活性和可维护性。

自由贸易协定的本地化适配

在全球化的商业环境中，产品定义和自由贸易协定的本地化变得至关重要。以下是关于如何将自由贸易协定的概念本地化并集成到应用程序服务中的详细指南。

1. 产品定义与自由贸易协定

在讨论中，我们认识到没有必要在本地采用与原概念完全相同的产品定义。我们称之为’自由贸易协定’的信息，需要被适当地本地化。

2. 应用程序服务与依赖注入

我们的应用程序服务依赖于注入的组件。重要的是，产品定义（PIM）并没有公开到应用程序中，而是期望以’自由贸易协定’值对象的形式输出。

3. 服务接口的定义

定义一个接口，具有具体的基础设施实现，可以帮助我们专注于服务的意图，而不是具体的实现细节。这符合SOLID原则中的开闭原则，即软件实体应对扩展开放，对修改封闭。

4. 翻译服务的角色

翻译服务（TranslatingFreeTradeAgreementService）的目的是将外国概念转化为符合本地语言和习惯的内容。它依赖于适配器来获取数据，并作为编排者将数据传递给转换器。

5. 适配器与转换器的职责

适配器：负责从外部系统获取数据，例如使用HTTP或gRPC协议，并将数据传递给转换器。- 转换器：接收适配器提供的数据，验证数据结构，执行必要的转换，并创建所需的值对象。

6. 避免复杂性

虽然这个结构包含多个组件，可能会让一些人觉得复杂，但是否采用这种结构取决于您的开发生态系统、编程语言和工具。以下是每个组件的简要总结和实际应用建议：

服务接口：帮助您专注于服务意图，简化测试过程。- 翻译服务：确保知道需要联系哪些服务以获取本地概念。- 适配器：作为数据获取和传递的中间件。- 转换器：负责数据验证和转换，不包含业务规则。

7. 组件间的关系

组件间的关系可以通过一个清晰的图表来展示，但在这里我们用文字描述它们如何相互作用。

结论

最后，是否采用这种结构，以及如何实施，取决于您的具体需求和偏好。每个组件都有其特定的目的和职责，理解它们可以帮助您更有效地设计和实现应用程序服务。

接口、翻译、适配器和翻译器角色

在软件开发过程中，实现不同系统或模块间的无缝集成是一项挑战。以下是一些关键点，以帮助您更好地理解这些概念和它们在集成过程中的作用。

垂直开发方法遵循垂直开发方法，即从顶层到底层逐步开发，可以确保每个层次都紧密集成。这种方法有助于在开发过程中不断迭代和重构代码，以适应需求的变化。

功能分解随着对所需集成的深入了解，功能分解变得更加容易。这要求开发者对业务需求有清晰的认识，并能够将其转化为技术实现。

结论集成多个边界上下文是软件开发中的常态。了解和维护这些边界上下文之间的关系至关重要。这种集成不是神秘的黑魔法，而是需要时间和研究的科学。

通信方式选择在决定依赖同步或异步通信时，REST或gRPC是两个重要的通信协议。选择哪种协议应基于对集成关系和领域语言的深入理解。

后续内容预告在下一篇文章中，我们将探讨聚合设计，分析两个以上实体之间的简单关系，以及它们何时构成一个聚合。这将帮助我们更好地理解在复杂系统中管理实体间关系的策略。

注意：以上内容是对原文的重新编写，以增强条理性和结构性。

文章目录