我發現一個聲明，說明根據DDD設計的域模型不應該被用作REST API中的資源（source）。爲什麼在REST API中不應將域模型用作資源？
很明顯，REST API是應用程序的契約，而領域模型是實現的一部分，因此最好將這兩件事分開，以便領域模型中的更改不會自動意味着REST API的變化。但是，我認爲如果是小項目（REST API只有一個消費者 - 由一個團隊開發的javascript前端），擁有單獨模型的好處並不能證明分離模型的成本（不同類 - 域模型和資源表示以及模型之間的映射代碼）。顯然，域層不能有任何對REST特定基礎結構代碼的引用（以保持關注點分離）。
域和REST模型應該分開嗎？
使用DDD時，應始終將REST API與域模型分開。
這樣做的主要原因是簡化 - 您不想通過API向客戶端泄漏域模型的複雜性。否則，客戶需要了解您的域名的細微差別和複雜性，這很可能使API很難使用。
而使用DDD的主要驅動程序是一個複雜的問題領域，所以這總是一個問題。
不過，我認爲在小項目（＆hellip;）情況下，具有獨立的模型並不能證明分離模型的成本（＆hellip;）的好處。
我同意有項目，其中分離的域模型和REST API是過度工程。但是，這些案件不是DDD的候選人，因爲您不會從DDD中獲益足以證明其成本。
我認爲還有一件事要考慮的是誰使用你的REST API。如果您正在開發應用程序的前端，那麼您可以說所有事情都在1範圍內發生。只有一部分生活在客戶端/ javascript中。在那種情況下，我認爲在你的rest API中公開你的模型確實有意義。
在這種情況下，REST API可能只是一種與您的域服務通信的方式。
爲什麼在REST API中不應將域模型用作資源？
因爲網絡是一個完全不同於你的核心領域層的世界。由於HTTP只有少數動詞，因此實體中的方法特別難以翻譯。如果您想通過REST公開您的應用程序，則必須將您的域名流程轉換爲HTTP，這通常意味着要做出妥協並設計與您的域實體不同的資源。
當然，您應該在HTTP客戶端和服務器之間以及域應用程序協議之間交換的消息中找到無處不在的語言中的術語，如果您正在進行HATEOAS，但Web必然會扭曲您的域表示形式。
REST的重點不在於重新創建您的域及其流程的高保真模型，而是以符合HTTP的方式提供它們，同時儘可能減少翻譯中的損失。但它仍然是一個翻譯。
根據您的域模型，您可以將業務邏輯掛接到REST資源。例如，每當有人設置is_published = 1時，您可以通過掛鉤到事件或增變器來通知管理員，執行額外的驗證等。有時候事情可能太複雜而且很奇怪，所以你可以標記某些屬性爲不可修改的，然後創建自定義操作來修改它們，如果這樣做合理的話。我認爲，如果你設計得當，你甚至不需要這些「自定義操作」。 Facebook不會使用Graph API，我不認爲。我正在考慮開發一個基於暴露模型層的框架，我仍然認爲這是一個好主意。