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

Question

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

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

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

据我所知，聚合根的概念适用于我的持久性/域层，不应该成为我的 View 层的关注点(在我的情况下是 JSON 或 XML 资源表示)。

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

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

GET /api/v1/listing/465489

和

GET /api/v1/listing/465489/item

无论Listing是否是Item的聚合根。

我在这里是正确的还是我需要在开始实现任何代码之前调整我对这一点的理解？

Answer 1

I'm using this as an exercise to better understand Domain Driven Design approach as for the most part it seems like a good approach.

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

As far as I can tell, the concept of the aggregate root is applicable to my persistence/domain layer and should NOT be a concern of my view layer (in my case JSON or XML resource representations).

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

would this mean that it is still okay to expose non aggregate root resources via URI endpoints in my REST API or am I 'constrained' to only exposing aggregate roots through my API's endpoint?

这取决于你的意思。在任何情况下，您都没有“暴露”您的聚合根，您正在调整您的域模型以适应网络。这意味着您的客户正在操纵资源，并且作为这种副作用，资源操纵域模型。
因此，您从 api 发送到域模型的消息仍将发送到聚合根，并且需要进一步遍历才能到达非根实体。
对于 safe 的操作，你根本不需要聚合根。 CQRS模式就是建立在这个想法之上的；您可以读取先前缓存的模型状态表示，而不会冒业务不变性的风险。因此，创建具有不可变语义的资源以提供对域中实体的访问是可以的。
然而，不安全的操作更棘手——您需要采用您公开的统一接口(interface)的语义，并将其转换为适当的消息以发送到聚合根 - 因为它位于根之后验证更改是否实际存在。