DDD - 跨有界上下文边界聚合根实体使用

Question

在域模型中建模实体身份的一种建议方法是创建值对象而不是使用原始类型（例如，在C＃中）：

public class CustomerId
{
  public long Id { get; set; }
}

在我看来，这些类应该在整个应用程序中使用，而不仅仅在域模型中使用。与命令和事件一起，他们可以为有界上下文定义服务契约。现在，在一个具有多个有界上下文的消息/事件驱动架构中，每个都有一个单独的服务契约，很容易遇到循环依赖。

在有界上下文之间的通信中，您将拥有适配器和转换器，并且通常大多数属性将被压缩为本地值。但是如何处理生活在其他有限环境中的聚合根的身份呢？ 此问题的一个解决方案是为外部（远程）实体的标识类创建本地上下文同级类。但这违反了DRY原则。另一种方法可以是将所有有界上下文的合同放在一个程序集中。我在许多CQRS示例中看到了这一点，在我看来这是代码味道。作为最后的解决方案，可以将所有合同（事件和命令）中的标识类分解回原始类型，并让每个有界上下文在域模型中组合回本地标识类（如果需要）。但这可能导致复合身份上的错误身份构成（例如，UserId + TenantId）。

如何跨越有界的上下文边界处理您的项目中的身份共享？

Answer 1

如果您的客户在一个上下文中在其他上下文中具有不同的名称，例如销售中的 Lead 或运费中的 Receipient ，您会怎么做？ ？

如果每个人都有一个 CustomerId ，那么它就会违背一个上下文的概念和语言不会泄漏到其他环境中的目的。

不要误解我，我完全赞成将聚合ID封装在一个值对象中。但是每个上下文都应该有各自的实现，其名称与每个上下文中无处不在的语言一样。