考虑到领域事件模式和这个 post ，为什么人们建议为每个事务模型保留一个聚合？有一些很好的例子，一个聚合可以改变另一个聚合的状态。即使删除一个聚合(或改变它的身份)也将导致改变引用它的其他聚合的状态。有人说每个聚合保留一个事务有助于可扩展性(每个服务器保留一个聚合)。但是，这种思维方式是否打破了 DDD 的基本特征:技术不可知论？
因此，根据上述陈述和您的经验，设计聚合、领域事件会导致其他聚合发生变化，这是否会导致每个交易有 2 个或更多聚合(例如:下新订单时) 100 件商品将客户的状态从正常更改为 VIP )？
这里有几件事情在起作用，还有更多的权衡需要进行。
首先，你是对的，你应该首先考虑模型。毕竟，语言、模型和领域的相互作用正是我们做这一切的目的:提出精心设计的抽象作为问题的解决方案。 战术模式 - 来自 DDD 书 - 是达到目的的一种手段。在这方面，我们不应该过分强调它们，即使它们为我们提供了很好的服务(并给其他人带来了很大的麻烦)。它们帮助我们找到模型中的“一致性单元”、一起变化的事物、事务边界。恐怕这就是问题所在。当某事发生时以及它发生的副作用何时应该可见是两件不同的事情。然而，它们常常被视为一个整体，从而导致这种不舒服的感觉，我们通过试图将所有东西挤在边界内而不加质疑来回应这种感觉。尽管如此，我们仍然有那种不舒服的感觉。有很多事情在逻辑上可以被视为“整体变化”，而在物理上有多个小的变化。这需要技巧和经验，甚至是直率地试图知道什么时候是这种情况。请注意，并非所有事情都可以通过这种方式解决。 扩展还是不扩展，这通常是一个问题。如果您不需要扩展，将东西放在一个盒子上，满足于某种备份/恢复策略，您可以改变规则并一次性影响多个聚合。但是你必须意识到你只是在这样做，而不是将其视为理所当然，因为不可避免地会发生变化，它可能会扰乱这种特殊的处理方式。所以，公平警告。更微妙的是为什么要一次性更改多个聚合的问题。人们通常会用“你的总体边界是错误的”来回答这个问题。实际上，这意味着您有更多的领域和模型探索要做，以发现那些同步、多聚合变化的真正动机。通常，用户界面或服务具有这种“不合理”的期望。但可能还有其他原因，可能只需要一组不同的抽象来解决同一问题。这是 DDD 的一个非常重要的方面。 您给出的示例似乎我可以将其作为两个单独的事务处理:下订单，作为对此的 react ，因为下订单时包含 100 件商品，因此客户成为了 VIP。正如 MikeSW 在他的回答中暗示的那样(我在他发布他的之后开始写我的)，问题是何时、谁、如何以及为什么要观察到这种客户状态的变化。基本上是“下一个”行为决定了先前行为的一致性要求。