2015-09-10 52 views
5

我工作在公開REST API的後端應用程序上,並嘗試在我的項目中使用域驅動設計。API基礎結構類應該是DDD中域的一部分嗎?

REST API對一組固定的域類進行操作。對於來自域的每個Agregate根,都有一個單獨的REST端點。然而,儘管所有的努力,也有情況下,當新類,而不是從域類(基礎設施類)派生出來,如:

  • 批量操作[{"id": 1, "status": "success"},{"id": 2, "status": "failure", "message": "detailed message"}]
  • 一類列一類控股狀態由用戶選擇[{"column": "id", "order": 1}, {"column":"created", "order": 2 }]

現在兩個選項:

  • 是否確定有REST API暴露是不是一部分的類域名?
  • 或者這些類應該成爲域的一部分?
+1

我認爲完全可以公開特定於圖層的合同。例如,DTO通常在應用程序層中定義... – plalx

回答

5

您不應該嘗試直接針對您的域模型構建REST API。您需要承擔相當多的責任,因爲這樣的界面會混淆您的域模型。例如。事務控制,安全性,輸入驗證是您可能需要的東西,但不屬於域模型。

這是應用程序服務的用途。

建立層圍繞你的域模型包含應用程序服務(通常稱爲服務層)。應用程序服務是域模型的直接客戶端。它們通常組織在用例而不是聚合。現在,您的REST API是應用程序服務的直接客戶端,而不是域模型。

您提到的兩個類然後也很適合服務層。

編輯:

注意,使用六角架構(這是一個非常適合DDD)時,服務層是不一樣的持久層。服務層使用持久層加載並將聚合保存到數據庫。

+0

應用程序層基礎結構是不可知的嗎?所以REST框架是應用程序層的第一個客戶端? – danfromisrael

+0

@danfromisrael看到我更新的答案 – theDmi

+0

感謝@theDmi的答案。我完全同意你所描述的方法,但我有一個問題。假設我們有一個GET方法返回對象列表,每個對象都有一個狀態列。現在我們需要創建一個新的GET方法,它將返回一個唯一狀態列表以及具有此狀態的元素數量。爲此,我們創建一個具有兩個屬性的新DTO類:「字符串狀態」和「長計數」。在哪一層應該定義這個類?應用程序,對嗎?基於DDD的存儲庫是否應該返回應用程序層類的實例? –

相關問題