在领域驱动设计中，当一个限界上下文需要引用另一个限界上下文的聚合id时，直接导入id定义会引入不必要的耦合。本文探讨了这种场景下的最佳实践，推荐通过在引用方限界上下文内重新定义id结构来保持各上下文的独立性，即使这违反了dry原则，因为id变更的低频性和高协调成本使得重复的弊端远小于紧耦合的风险。
引言：跨限界上下文ID引用的挑战
在复杂的企业应用中，系统通常被划分为多个限界上下文（Bounded Context），每个上下文负责其特定的领域和业务逻辑。然而，在实践中，一个限界上下文中的实体可能需要引用另一个限界上下文中的聚合根（Aggregate Root）的标识符（ID）。例如，一个“订单”上下文中的订单项可能需要引用“产品”上下文中的产品ID。此时，核心问题在于：我们应该直接导入并重用产品上下文定义的 ProductId 类型，还是在订单上下文内部重新定义一个本地的 ProductId 类型？这涉及到领域驱动设计中“单一职责原则（DRY）”与“限界上下文独立性”之间的权衡。
理解限界上下文与耦合
限界上下文是领域驱动设计中的核心概念，它定义了一个特定领域模型的边界。在这个边界内，领域术语和概念具有明确、统一的含义（即无处不在的语言）。每个限界上下文都应尽可能地保持独立和自治，以降低系统复杂性，促进团队协作，并允许独立演进。
直接从一个限界上下文（如 Context1）导入另一个限界上下文（如 Context2）的类型定义（如 ExampleEntity1ID）会引入显式的代码耦合。这意味着 Context2 现在直接依赖于 Context1 的内部实现细节。这种耦合带来的问题包括：
- 脆弱性：如果 Context1 中的 ExampleEntity1ID 定义发生改变，Context2 可能会受到影响，甚至需要修改代码，即使这种改变对 Context2 的业务逻辑没有直接意义。
- 部署与测试复杂性：两个上下文的部署和测试不再完全独立，需要协调。
- 概念泄漏：Context2 可能会无意中采纳 Context1 的内部概念和语言，模糊了上下文边界，损害了各自无处不在的语言的清晰性。
推荐策略：重新定义ID结构
面对跨限界上下文的ID引用，推荐的策略是在引用方限界上下文内部重新定义（或使用一个简单的原始类型如字符串或UUID）该ID的结构，而不是直接导入。这意味着我们在此场景下选择“打破DRY原则”，以维护限界上下文的独立性。
为什么打破DRY是更优解？
- ID的特性：聚合ID通常是简单的值对象，例如一个字符串、UUID或整数。它们的内部结构和行为通常非常稳定，且不包含复杂的领域逻辑。
- 变更频率与成本：聚合ID的表示形式（例如，从UUID变为自定义字符串格式）变更的频率极低。当这种变更确实发生时，它通常是一个重大且影响深远的事件，需要跨多个团队和系统的高度协调。在这种情况下，即使存在多处重复的ID定义，变更时也极不可能“遗漏”某个副本，因为整个变更过程会非常谨慎和严格。DRY原则旨在避免因代码重复而导致的维护遗漏，但在ID变更这种特殊情况下，其优势被削弱。
- 优先级：在领域驱动设计中，限界上下文的独立性、解耦以及清晰的边界通常比严格遵循DRY原则具有更高的优先级，尤其是在处理简单的、稳定的值对象时。牺牲一点代码重复性，换取更松散的耦合和更清晰的领域边界，是值得的。
代码示例与对比
为了更好地说明这两种方法的差异，我们以Python为例：
假设 Context1 定义了 ExampleEntity1 及其ID：
# domain/context_1/models.py
class ExampleEntity1ID:
"""ExampleEntity1在Context1中的唯一标识符"""
def __init__(self, value: str):
if not value:
raise ValueError("ID value cannot be empty")
self.value = value
def __eq__(self, other):
if not isinstance(other, ExampleEntity1ID):
return NotImplemented
return self.value == other.value
def __hash__(self):
return hash(self.value)
def __str__(self):
return self.value
class ExampleEntity1:
"""Context1中的聚合根"""
def __init__(self, id: ExampleEntity1ID, some_field_1: str):
self.id = id
self.some_field_1 = some_field_1现在，Context2 中的 ExampleEntity2 需要引用 ExampleEntity1ID。
不推荐的做法：直接导入
这种方法直接从 Context1 导入 ExampleEntity1ID。
# domain/context_2/models.py
from domain.context_1.models import ExampleEntity1ID # <-- 引入了对Context1的直接依赖
class ExampleEntity2ID:
"""ExampleEntity2在Context2中的唯一标识符"""
def __init__(self, value: str):
if not value:
raise ValueError("ID value cannot be empty")
self.value = value
def __eq__(self, other):
if not isinstance(other, ExampleEntity2ID):
return NotImplemented
return self.value == other.value
def __hash__(self):
return hash(self.value)
def __str__(self):
return self.value
class ExampleEntity2:
"""Context2中的聚合根，引用Context1的ID"""
def __init__(self, id: ExampleEntity2ID, example_entity_1_id: ExampleEntity1ID, some_field_2: str):
self.id = id
self.example_entity_1_id = example_entity_1_id # 使用导入的ID类型
self.some_field_2 = some_field_2这种做法导致 domain/context_2/models.py 与 domain/context_1/models.py 之间存在编译时（或运行时）依赖，一旦 ExampleEntity1ID 的定义在 Context1 中发生不兼容的改变，Context2 就会受到影响。
推荐的做法：重新定义或使用原始类型
这种方法在 Context2 内部定义一个本地的ID类型，或者直接使用一个原始类型（如 str）来表示 ExampleEntity1ID。
# domain/context_2/models.py
# 无需导入 domain.context_1.models
class ExampleEntity2ID:
"""ExampleEntity2在Context2中的唯一标识符"""
def __init__(self, value: str):
if not value:
raise ValueError("ID value cannot be empty")
self.value = value
def __eq__(self, other):
if not isinstance(other, ExampleEntity2ID):
return NotImplemented
return self.value == other.value
def __hash__(self, other):
return hash(self.value)
def __str__(self):
return self.value
# 在Context2中重新定义对ExampleEntity1ID的本地表示
# 它可以是一个简单的字符串，或者一个本地的值对象，其结构与Context1中的ID相似但独立
class ReferencedExampleEntity1ID:
"""在Context2中对Context1的ExampleEntity1ID的本地表示"""
def __init__(self, value: str):
if not value:
raise ValueError("ID value cannot be empty")
self.value = value
def __eq__(self, other):
if not isinstance(other, ReferencedExampleEntity1ID):
return NotImplemented
return self.value == other.value
def __hash__(self):
return hash(self.value)
def __str__(self):
return self.value
class ExampleEntity2:
"""Context2中的聚合根，引用Context1的ID"""
def __init__(self, id: ExampleEntity2ID, example_entity_1_id: ReferencedExampleEntity1ID, some_field_2: str):
self.id = id
self.example_entity_1_id = example_entity_1_id # 使用本地定义的ID类型
self.some_field_2 = some_field_2
# 或者，如果ID只是一个简单的字符串/UUID，可以直接使用原始类型：
# class ExampleEntity2:
# def __init__(self, id: ExampleEntity2ID, example_entity_1_id: str, some_field_2: str):
# self.id = id
# self.example_entity_1_id = example_entity_1_id
# self.some_field_2 = some_field_2通过这种方式，Context2 完全解除了对 Context1 内部ID实现的依赖。即使 Context1 更改了 ExampleEntity1ID 的内部结构（例如，添加了新的验证逻辑），只要其外部表示（如字符串值）不变，Context2 就不需要修改。如果 Context1 彻底改变了ID的格式（例如，从UUID变为复合字符串），那么 Context2 确实需要更新其 ReferencedExampleEntity1ID 的定义，但这属于前面提到的“重大变更”，需要跨团队协调，因此不会因为代码重复而导致遗漏。
关于共享内核的考量
有时，为了在多个限界上下文之间共享某些核心概念，领域驱动设计会引入“共享内核（Shared Kernel）”模式。共享内核是一个包含少量、紧密耦合、被多个上下文共同使用的代码和领域模型的独立模块。然而，对于简单的聚合ID，通常不建议将其放入共享内核。
将聚合ID提升到共享内核意味着它成为了一个跨上下文的通用概念，但聚合ID本质上是其所属聚合的标识，是该聚合内部的实现细节，其生命周期和语义应由其拥有者上下文管理。将它放入共享内核会增加共享内核的负担，并可能导致不必要的依赖，使得共享内核变得臃肿。共享内核更适用于那些真正被多个上下文共享的、复杂的、具有丰富行为的领域概念。
总结与最佳实践
在限界上下文之间引用聚合ID时，最佳实践是优先考虑上下文的独立性和解耦，而非严格遵守DRY原则。
- 优先解耦：避免直接导入其他限界上下文的ID类型定义。
- 本地表示：在引用方限界上下文内部，重新定义一个本地的ID类型（即使其结构与被引用ID相同），或者直接使用一个原始类型（如 str 或 UUID）来表示。
- 评估变更成本：对于ID这类结构稳定、变更频率低且变更成本高的值对象，代码重复的弊端远小于因紧耦合带来的维护和演进风险。
- 慎用共享内核：聚合ID不适合放入共享内核。共享内核应保留给那些真正需要被多个上下文共享的、复杂的领域概念。
通过采纳这种策略，我们可以构建出更加健壮、灵活且易于维护的领域驱动设计系统，确保每个限界上下文都能独立演进，从而更好地应对业务变化。
