聚合根在 REST API (DDD) 中的作用

Question

我正在为在线拍卖服务创建一个新的 REST/超媒体 API。

我将此作为练习来更好地理解领域驱动设计方法，因为在大多数情况下，这似乎是一种很好的方法。

我的一些实体的示例是：Item、Listing、Bid、Purchase、BidHistory 等。 我将列表实体标识为一个聚合根，我计划通过它管理投标、项目等。

据我所知，聚合根的概念适用于我的持久性/域层，不应该是我的视图层的关注点（在我的例子中是 JSON 或 XML 资源表示）。

是这样吗？如果是这样，这是否意味着仍然可以通过我的 REST API 中的 URI 端点公开非聚合根资源，或者我是否“受限”只能通过我的 API 端点公开聚合根？

我的想法是聚合根在持久性对象的领域中，它在概念上与域模型是分开的，所以我应该能够公开两个 URI，例如：

GET /api/v1/listing/465489

和

GET /api/v1/listing/465489/item

不管Listing是否是Item的聚合根。

我在这方面是否正确，或者我是否需要在开始实施任何代码之前调整我对这一点的理解？

Answer 1

我将其用作练习，以更好地理解领域驱动设计方法，因为在大多数情况下，这似乎是一种很好的方法。

好的...但它们是正交问题，所以要小心。

据我所知，聚合根的概念适用于我的持久性/域层，不应该是我的视图层的关注点（在我的例子中是 JSON 或 XML 资源表示）。

没错 - 聚合是您的业务领域的分区。资源是集成域的一部分。请参阅 Jim Webber 的演讲 REST - DDD in the Large。

这是否意味着仍然可以通过我的 REST API 中的 URI 端点公开非聚合根资源，或者我是否“受限”只能通过我的 API 端点公开聚合根？

这取决于你的意思。在任何情况下，您都没有“暴露”您的聚合根，而是调整您的网络域模型。这意味着您的客户正在操纵资源，而作为副作用资源操纵域模型。

因此，您从 api 发送到域模型的消息仍将发送到聚合根，并且需要进一步遍历才能到达非根实体。

对于safe 的操作，您根本不需要聚合根。 CQRS 模式就是建立在这个想法之上的；您可以读取先前缓存的模型状态表示，而不会冒业务不变性的风险。因此，创建具有不可变语义的资源以提供对域中实体的访问是很好的。

然而，不安全的操作比较棘手——您需要获取所公开的统一接口的语义，并将其转换为适当的消息以发送到聚合根 - 因为它位于根之后验证更改的权限确实存在。