domain-driven-design - 多个聚合处理一张表？

Question

我们正在建模一个订单系统，我们有订单的概念。订单从创建到交付都有一个生命周期，在它们之间，订单可以处于其他状态。一些状态具有特定的业务逻辑，并且有时共享其他业务逻辑，例如如果订单未按时完成，订单何时可以在具体日期到期。

好吧，团队正在怀疑是否

1. 使用状态模式（一个聚合，一个存储库），或者
2. 使用一个聚合/存储库来处理订单的每个状态。

在第二种方法中，我们正在考虑为每个存储库使用相同的表，以便有一个表顺序来持久/加载每个聚合。从 DDD 的角度来看是不是很清楚？

你有什么想法？

标签： domain-driven-design

Answer 1

一般而言，DDD 就是不因基础设施问题而污染领域；不同的聚合是否存储在同一个表中是一个基础架构问题。只要存储库/存储库能够履行其义务，就去做。

也就是说，在哪些操作是合法的以及从一个州到另一个州可以获得哪些信息方面，有一个订单有很多变化，这可能表明将这些州分配到不同的有界上下文（例如，项目所在的上下文）是有意义的。添加到订单（例如购物车上下文）、结帐/付款上下文、交付上下文的程序集和正在交付上下文）。