在DDD中打包存儲庫及其接口

Question

在DDD之後的應用程序中，我們傾向於有一個服務層，其中包含服務+存儲庫+存儲庫和服務的接口，它們都位於同一個程序集中，而域模型將生活在不同的組裝中。感覺所有不適合領域模型的東西都混雜在這個大項目中。

在遵循DDD原則和模式的應用程序中，如何打包存儲庫及其實現的接口？打包DDD應用程序的不同邏輯部分的最佳實踐是什麼（或者就此而言通常是打包）？每個邏輯分區應該在自己的程序集中嗎？它甚至重要嗎？

Answer 1

我會看看洋蔥建築。基本上所有域服務的域模型和接口都被認爲是核心。圖層僅取決於靠近核心的圖層。他們的實際實施由基礎設施處理。

這裏http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

見最後你的接口是什麼定義應用程序。如何實施的邏輯是外部化的。所以我希望你有與領域模型和域服務，前端（如MVC等），然後是一個基礎設施大會，實現諸如提供數據等NHibernate的東西的程序集。

你可以看到各種樣品，實施鏈接文章各個部分的體系結構。最簡單的是這裏https://bitbucket.org/jeffreypalermo/onion-architecture/get/1df2608bc383.zip

您可以看到與在這裏https://stackoverflow.com/questions/tagged/onion-architecture

主要好處是，它主要是基礎設施的擔憂，這將是最經常發生變化的問題。新的數據層技術，新的文件存儲等。另外，你的核心領域應該是相當穩定的，因爲它沒有實現任何東西，只是通過契約（接口）來定義它需要的東西。通過將實現問題放在一個位置，可以最大限度地減少組件中所需的更改量。

Answer 2

您可以在DDD book中找到設計圖層的指南。你基本上有：

• 域
• 基礎設施
• 應用
• UI

服務進來三種：應用層服務，基礎設施服務層和域層服務，視關於服務的功能。至於存儲庫，他們的合同（接口）通常駐留在域中，而他們的具體實現在基礎設施層中。

關於程序集，我建議每層至少一個。程序集和dll都是關於可重用性，關注點分離和解耦的 - 我能夠選擇該dll並放到其他應用程序中重用它嗎？我能否這樣做而不拖動一堆無關的功能，這會給其他應用程序帶來不必要的複雜性？我可以通過更改依賴注入模塊中的一行代碼輕鬆地將我的dll替換爲另一個dll嗎？等等。