聚合根在 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模式就是建立在這個想法之上的； 您可以讀取先前緩存的模型狀態表示，而不會冒業務不變量的風險。 因此，創建具有不可變語義的資源以提供對域中實體的訪問是很好的。

然而，不安全的操作更棘手——你需要獲取你公開的統一接口的語義，並將其轉換為適當的消息以發送到聚合根——因為它的權限在根后面驗證更改實際上是有效的。