事件源和跨上下文聚合

Question

我有这样的想法:在不同的有界上下文中使用不同的写模型，但它们都是相同的聚合实例(相同的事件)。

例如，考虑在管理和用户上下文中使用的用户聚合(即应用程序的管理部分和用户界面部分)。域模型指出，用户(在用户上下文中)不能对自己执行任何操作(更改电子邮件、更改密码、更改地址等)，除非他已登录(这是允许他在未登录的情况下进行的唯一操作)。

但是，在管理上下文中，该操作不需要该用户登录(基本上，管理员可以代表他更改用户的详细信息)。

是否可以将事件源建模为单个聚合实例(相同的ID)，但取决于上下文，将根据事件构建不同的对象模型？也就是说，在管理上下文中，模型不会验证用户是否登录，但是在用户上下文中，模型会这样做。这样，事件就可以在上下文中共享。

这是个好主意吗我能闻到一些问题，但我不能完全确定。

Answer 1

我有这样的想法:在不同的有界上下文中使用不同的写模型，但它们都是相同的聚合实例(相同的事件)。

在我看来，这是个坏主意；与最佳实践非常矛盾。

总体确实需要有一个真理的来源。在事件源实现中，这实际上是聚合的历史。这一历史的一致性是由总量本身所保护的。如果聚合有两个不同的实现(两种不同的业务规则集合--它们允许不同的状态)，那么当一个实现将历史遗留在另一个应该阻止的状态时，您就会陷入真正的混乱。

但是，两个不同的应用程序可以(潜在地)共享相同的域模型。在您的情况下，这可能意味着当另一个上下文禁止命令时，其中一个上下文允许命令。

然而，在最初的蓝皮书中，有界上下文是模型可能不适用的边界，无处不在的语言变化等等。如果用来描述业务的词语不再意味着同样的事情，那么共享相同的集合似乎是不明智的。

另见：有了这些服务，我又怎能不贫血呢？

请注意，从同一历史中读取它们的状态的两个不同的投影绝对没有什么问题。用户上下文可以有一个历史视图，其中管理上下文对同一历史有一个完全不同的视图。

Answer 2

我有这样的想法:在不同的有界上下文中使用不同的写模型，但它们都是相同的聚合实例(相同的事件)。

有界上下文(BCs)背后的想法是有一个非常明确的目的，允许开发人员在没有权衡的情况下解决一个定义良好的问题。

在两个BCs中使用相同的集合是没有意义的，根据定义:不同的BCs有不同的目的，而同一模型服务于不同的目的会很快导致意外的复杂性。

您可以使用非常相似或重叠的数据进行BCs，但这是另一回事(深入了解这些数据将显示出有趣的细节)。聚合是围绕行为形成的，而不是数据。

Answer 3

除了其他答案提到的问题外，你似乎是在混淆担忧。

用户登录的事实是应用程序级别的问题，而不是域问题。不应该使用它来执行聚合内部的不变量。

访问和权限控制是一个交叉的关注，在大多数DDD系统不是烤在领域，而是由一个单独的基础设施模块提供的边缘的系统。