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

Question

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

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

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

据我所知，聚合根的概念适用于我的持久性/域层，不应该是我的视图层的问题（在我的例子中是 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。

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

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

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

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

然而，不安全的操作更棘手——你需要获取你公开的统一接口的语义，并将其转换为适当的消息以发送到聚合根——因为它的权限在根后面验证更改实际上是有效的。