DDD-跨有界上下文边界的聚合根身份使用 [英] DDD - aggregate root identity usage across bounded context bounderies

问题描述

在域模型中为实体身份建模的一种建议方法是创建值对象，而不是使用原始类型(例如，在C#中):

One suggested way to model entity identities in a domain model is to create value objects instead of using primitive types (f.e. in C#):

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

在我看来，此类应在整个应用程序中使用，而不仅应在域模型中使用.它们与命令和事件一起可以为有限的上下文定义服务协定.现在，在消息/事件驱动的体系结构中，具有多个有界上下文且每个上下文具有单独的服务协定，很容易遇到圈子依赖关系.

In my opinion this classes should be used throughout the whole application and not only in the domain model. Together with commands and events they can define a service contract for a bounded context. Now in an message/event driven architecture with multiple bounded contexts and each having a separate service contract it is easy to run into circle dependencies.

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

In the communication between bounded contexts you will have adapters and translators and usually most properties will be crunched into local values. But how to deal with identities of aggregate roots living in other bounded contexts? One solution to this problem is to create local context sibling classes for identity classes of foreign (remote) entities. But this violates somehow the DRY principle. An other approach could be to place the contracts for all bounded contexts in one assembly. I've seen this in many CQRS examples and in my opinion this is code smell. As a last solutions one can decompose the identity classes back to primitive types in all contracts (events and commands) and let each bounded context compose back his local identity classes (if needed) in the domain model. But this could lead to wrong identity compositions on compound identities (f.e. UserId+TenantId).

您如何处理项目中跨界上下文共享的身份?

How do you deal in your projects with identity sharing across bounded context boundaries?

推荐答案

如果您的 Customer 在一个上下文中在其他上下文中具有不同的名称，例如 Lead 在销售中还是在收货人在运输中?

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?

如果它们每个都有一个 CustomerId ，则它违背了一个上下文的概念和语言不泄漏到其他上下文中的目的.

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

不要误会我的意思，我完全赞成将聚合ID封装在一个值对象中.但是每个上下文都应该有自己的实现，并以每个上下文的无所不在的语言来命名.

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.

这篇关于DDD-跨有界上下文边界的聚合根身份使用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！