DDD -跨有界上下文边界的聚合根标识使用
本文关键字：标识 边界 上下文 DDD | 更新日期: 2023-09-27 18:11:11
在域模型中建模实体标识的一种建议方法是创建值对象而不是使用基本类型(如c#):
public class CustomerId
{
public long Id { get; set; }
}
在我看来，这些类应该在整个应用程序中使用，而不仅仅是在领域模型中。与命令和事件一起，它们可以为有界上下文定义服务契约。现在，在消息/事件驱动的体系结构中，有多个有界上下文，每个上下文都有一个单独的服务契约，很容易遇到循环依赖。
在有界上下文之间的通信中，您将使用适配器和转换器，并且通常大多数属性将被压缩为局部值。但是，如何处理生活在其他有限环境中的聚合根的身份呢?这个问题的一个解决方案是为外部(远程)实体的标识类创建本地上下文兄弟类。但这在某种程度上违反了DRY原则。另一种方法是将所有有界上下文的契约放在一个程序集中。我在许多CQRS示例中看到过这种情况，我认为这是代码气味。作为最后一种解决方案，可以将标识类分解回所有契约(事件和命令)中的基本类型，并让每个有界上下文在域模型中组合回其本地标识类(如果需要)。但是这可能会导致复合标识上的错误标识组合(例如UserId+TenantId)。
在你的项目中，你如何处理跨边界上下文的身份共享?
如果您的客户在一个上下文中在其他上下文中有不同的名称，例如在销售中Lead或在运输中收件人，您将如何处理?
如果它们都有一个CustomerId，那么它违背了一个上下文的概念和语言不泄漏到其他上下文的目的。
不要误解我，我完全赞成将聚合id封装在值对象中。但是，每个上下文都应该有自己各自的实现，并在每个上下文的通用语言中使用它们的名称。