關於DDD結構和分層。

Question

民間， 道歉，如果這已被覆蓋在另一個線程，但我已經搜查ddd和mvc文章，並沒有找到一個直截了當的答案。

我希望能夠將DDD方法應用於我的MVC項目的體系結構。請糾正我錯在哪裏。

所有涉及到域模型的MVC控制器操作最初都會打到 和應用程序服務層。 此處的應用程序服務層充當演示文稿和域之間的界面。 以後任何來自應用服務的明確涉及離散域聚合的請求將使用存儲庫對聚合根執行提取或修改操作。每個聚合根將擁有自己的存儲庫。

因此應用程序服務層必須注入域所需的任何/所有存儲庫。

如果一個操作可能涉及多個聚集或需要邏輯不適合整合到一個聚合中，那麼應用程序服務將調用一個域服務來跨聚合執行操作。

這看起來並不適合我。 我的困惑是，從DDD的角度來看，林不知道是否例如聚合根應該執行自己的持久性，即聚合獲取注入一個存儲庫，然後堅持/獲取本身或上面的應用程序服務層使用存儲庫行事或獲取聚合？

另外，如果應用程序服務層注入了所有的存儲庫，那麼應用程序服務層調用的域服務是否也需要注入存儲庫？

在這一點上我保持CQRS。我想先獲得分層和服務與聚合之間的關係。

感謝您的任何建議。

Answer 1

了涉及打擊域模型中的所有MVC控制器動作將 最初命中和應用服務層。這裏的應用程序服務層充當演示文稿和域之間的界面。

有爭議，但我會仔細考慮是否需要額外的圖層。它增加了許多樣板代碼並降低了可維護性 - 作爲某人pointed out recently，當您將相同原因（即您的服務方法和相應的域方法）進行更改時，您必須在系統中的許多不同位置進行更改。另一方面，您可能需要該服務層將您的域對象映射到DTO，但在那裏可以直接在Controller中完成，並且沒有任何東西會強制您使用to use DTOs in the presentation layer。

我的困惑是，從DDD角度林不知道是否爲 例如聚合根應該履行自己的持久性即 總被同一個存儲庫注入，然後持續/取 本身，還是作爲應用上述服務層使用 存儲庫來執行或獲取聚合？

聚合根管理自己的持久性通常被認爲是不好的做法，因爲它打破了持久性的無知並違反了單一責任原則。如果你這樣做了，你的聚合根類現在有2個改變理由，2個破壞代碼的原因，它不易維護等等。

你應該把保存在它的倉庫中的聚合根的責任委託給將知道應用程序執行上下文的對象（例如，Controller或應用程序層中的對象）。

此外，如果應用服務層與所有 庫注入，是否應用服務 層調用也需要倉庫域名服務注入？

是的，我認爲它非常有意義，尤其是如果域服務嚴重依賴於存儲庫。