DDD实践，如何在一个非常复杂的例子中识别实体和聚合

Question

书读得越多，我就越困惑。书上的例子不够复杂，也太理所当然了。

假设我正在开发一个航班搜索服务，根据给定的条件搜索航班及其产品（告诉我应该卖多少钱、退改签信息、行李信息等）。就像许多在线旅行社（OTA）一样。

这是我已经定义的类，层次结构如下：

└── FlightsAndProducts    flights and it's products.
    ├── list<Flight>    flights of this journey, list because it may be a transfer journey.
    └── list<ProductGroup> 
                    ├── Identifier    identifier because I may clone this ProductGroup and considiered as a different one
                    ├── list<Product>    all the products, list because one product refers to one flight.
                    │           ├── Identifier    identifier because I may clone this Product and considiered as a different one
                    │           ├── price
                    │           ├── Refund
                    │           ├── Change
                    │           └── Baggage
                    └── totalPrice    just a sum of all Product's price

如果独立于 ProductGroup，Product 对象就没有任何意义，因为我一起销售每个航班的所有产品，而不仅仅是单个产品。

这才是真正让我困惑的地方：

1. 我没有存储库，因为我需要的所有数据都是由单个第 3 方 rpc 服务提供的，只需一次调用。它只是一个搜索服务，所以我根本不需要保留任何数据。在这种情况下，我还需要聚合吗？

2. 如果我仍然需要一个聚合，哪一个应该是聚合根？ FlightsAndProducts 或 ProductGroup 或 Product？

3. 如果 FlightsAndProducts 应该是聚合根，那么 ProductGroup 和 Product 又如何呢？它们不能是聚合根，因为一个聚合根只能通过其标识符而不是对象引用来保存另一个聚合根。

我真的很期待有人教我哪个对象应该是聚合根，哪个对象应该是实体。

Answer 1

书读得越多，我就越困惑。

不是你的错。

---

AGGREGATE 是一组关联对象，我们将其视为一个单元以进行数据更改。 ——埃里克·埃文斯

如果您没有对程序中的信息进行更改，那么您（可能）不会从在设计中引入 AGGREGATE 模式中受益。

从第三方服务向您提供的信息可能最好理解为参考数据，而实体/聚合模式对于这些情况没有多大帮助。

Pat Helland 的 外部数据... 论文可能有助于审阅。