聚合根在 REST 中的作用 API (DDD)
The role of Aggregate roots in a REST API (DDD)
我正在为在线拍卖服务创建一个新的 REST/hypermedia API。
我将此作为练习来更好地理解领域驱动设计方法，因为在大多数情况下，它似乎是一种很好的方法。
我的一些实体的示例是：项目、清单、出价、购买、出价历史等。
我将 Listing 实体标识为聚合根，我计划通过它来管理 Bid、Item 等。
据我所知，聚合根的概念适用于我的 persistence/domain 层，不应该是我的视图层的问题（在我的例子中 JSON 或 XML 资源表示）。
是这样吗？如果是这样，这是否意味着通过我的 REST API 中的 URI 端点公开非聚合根资源仍然可以，或者我 'constrained' 是否仅通过我的 API 公开聚合根？端点？
我的想法是聚合根在持久性对象的领域中，它在概念上与域模型是分开的，所以我应该能够公开两个 URI，例如：
GET /api/v1/listing/465489
和
GET /api/v1/listing/465489/item
不管Listing是否是Item的聚合根。
在开始实施任何代码之前，我的思路是否正确，或者我是否需要调整对此的理解？
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 模式就是建立在这个想法之上的；您可以 读取 先前缓存的模型状态表示，而不会冒业务不变性的风险。因此，创建具有不可变语义的资源以提供对域中实体的访问是很好的。
但是，不安全的操作更加棘手——您需要获取所公开的统一接口的语义，并将其转换为适当的消息以发送到聚合根——因为它在root 验证更改的权限实际存在。
我正在为在线拍卖服务创建一个新的 REST/hypermedia API。
我将此作为练习来更好地理解领域驱动设计方法，因为在大多数情况下，它似乎是一种很好的方法。
我的一些实体的示例是：项目、清单、出价、购买、出价历史等。 我将 Listing 实体标识为聚合根，我计划通过它来管理 Bid、Item 等。
据我所知，聚合根的概念适用于我的 persistence/domain 层，不应该是我的视图层的问题（在我的例子中 JSON 或 XML 资源表示）。
是这样吗？如果是这样，这是否意味着通过我的 REST API 中的 URI 端点公开非聚合根资源仍然可以，或者我 'constrained' 是否仅通过我的 API 公开聚合根？端点？
我的想法是聚合根在持久性对象的领域中，它在概念上与域模型是分开的，所以我应该能够公开两个 URI，例如：
GET /api/v1/listing/465489
和
GET /api/v1/listing/465489/item
不管Listing是否是Item的聚合根。
在开始实施任何代码之前，我的思路是否正确，或者我是否需要调整对此的理解？
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 模式就是建立在这个想法之上的；您可以 读取 先前缓存的模型状态表示，而不会冒业务不变性的风险。因此，创建具有不可变语义的资源以提供对域中实体的访问是很好的。
但是，不安全的操作更加棘手——您需要获取所公开的统一接口的语义，并将其转换为适当的消息以发送到聚合根——因为它在root 验证更改的权限实际存在。