3

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

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

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

在有界上下文之间的通信中，您将拥有适配器和翻译器，并且通常大多数属性将被处理为本地值。但是如何处理生活在其他有界上下文中的聚合根的身份呢？这个问题的一种解决方案是为外部（远程）实体的身份类创建本地上下文兄弟类。但这在某种程度上违反了 DRY 原则。另一种方法可能是将所有有界上下文的合同放在一个程序集中。我在许多 CQRS 示例中都看到了这一点，我认为这是代码异味。作为最后的解决方案，可以在所有合约（事件和命令）中将身份类分解回原始类型，并让每个有界上下文在域模型中组合回他的本地身份类（如果需要）。

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

4

1 回答 1

2

What will you do if your Customer in one context has a different name in other contexts, say Lead in sales or Receipient in shipping?

If they each have a CustomerId then it defies the purpose of one context's concepts and language not leaking into other contexts.

Don't get me wrong, I'm totally in favor of encapsulating the aggregate ids in a value object. But every context should have their own respective implementations with their names as in each context's ubiquitous language.

于 2014-07-02T16:07:33.190 回答