我正在为在线拍卖服务创建一个新的REST /超媒体API。
我将此作为练习来更好地理解领域驱动设计方法，因为在大多数情况下，这似乎是一种很好的方法。
我的一些实体的一个例子是：Item，Listing，Bid，Purchase，BidHistory等。 我将列表实体标识为我计划管理Bid，Item等的聚合根。
据我所知，聚合根的概念适用于我的持久性/域层，不应该关注我的视图层（在我的案例中是JSON或XML资源表示）。
是这样的吗？如果是这样，这是否意味着在我的REST API中通过URI端点公开非聚合根资源仍然是可以的，或者我是否受到限制＆＃39;仅通过我的API端点公开聚合根？
我的想法是聚合根源于持久性对象的领域，它在概念上与域模型分离，因此我应该能够公开两个URI，例如：
GET /api/v1/listing/465489
和
GET /api/v1/listing/465489/item
无论列表是否是Item的聚合根。
我在这里是正确的，还是在开始实施任何代码之前，我是否需要调整对此的理解？
答案 0 :(得分：3)
我将此作为练习来更好地理解领域驱动设计方法，因为在大多数情况下，这似乎是一种很好的方法。
好的......但它们是正交问题，所以要小心。
据我所知，聚合根的概念适用于我的持久性/域层，不应该关注我的视图层（在我的例子中是JSON或XML资源表示）。
这是正确的 - 聚合是您的业务域的分区。资源是集成域的一部分。请参阅Jim Webber演讲REST - DDD in the Large。
这是否意味着我可以通过我的REST API中的URI端点公开非聚合根资源，或者我是否受约束＆＃39;仅通过我的API端点公开聚合根？
这取决于你的意思。你不是在暴露＆＃34;在任何情况下，您的聚合根源都是适应您的网络域模型。这意味着您的客户正在操纵资源，作为副作用，资源操纵了域模型。
因此，您从api发送到域模型的消息仍将发送到聚合根，并且需要进一步遍历才能到达非根实体。
对于safe的操作，您根本不需要聚合根。 CQRS模式建立在这个想法之上;您可以读取以前缓存的模型状态表示，而不会有业务不变的风险。因此，使用不可变语义创建资源可以访问域中的实体，这很好。