我有一個標準的Order/OrderLineItem設置。DDD/DI（Unity）/ .NET /組合根 - 域服務
一天中產生的退款數量在一天中持續存在，退款包含一個訂單ID和一個或多個LineItemId's。我需要在一天結束時將這些（在Windows服務中）合併到適當的信用卡，禮品卡，獎勵卡等。
我一直在閱讀Mark Seemann's book，並可以看到使用Composition Root沙漏一個對象圖的好處。
整合過程本身就是我需要做最多構圖的地方。
我不明白的是這個合併邏輯應該在哪裏結束？我可以假設，無論合併邏輯結束的位置如何，我仍然只在組合根目錄中使用類似Unity的組合，並且組合應該很早就發生？
歡迎提供更多信息或澄清！
整合過程本身就是我需要做最多構圖的地方。
所以，你的意思是在你的系統中創建數據的過程是最多域對象被創建的地方嗎？
這是有道理的，並符合大多數應用程序。
我不明白這個合併邏輯究竟應該在哪裏結束？
固結邏輯將通過一個或多個服務組件，即有可能利用一個或多個組件repository和一種或多種unit of work部件來提供。該服務將在組合根中組成，您最終創建的任何存儲庫/工作單元也將組成該服務。
數據本身是完全動態的。您不能將應用程序構造爲靜態地知道數據的佈局，因此您無法將它組合到組合根中。你也不應該嘗試。相反，您的代碼可能使用ORM來定義或映射到您的域數據對象之間的關係模式。
然後，您可以使用存儲庫/工作單元從存儲中檢索數據。您還可以使用您的用戶界面/服務使用new來創建新數據 - 對於純粹是數據的域對象並不保證沒有依賴關係。將新數據或修改後的數據保存到存儲庫/工作單元。
如果這讓你畏縮，你總是可以使用從組合根注入的工廠模式來創建這些對象。但是，如果您將低級別域對象的結構設置爲DTOs，那麼即使有，也不會給您帶來太多收入。
因此，您不必使用Unity來提供所有內容，也不必在組合根中創建系統中的每個對象。但是，您應該嘗試編寫系統的靜態部分，或者甚至可以在組合根目錄中配置靜態可配置的系統動態部分。這非常適合像Unity這樣的DI容器。
如果您的退款項目只是數據容器或者對服務沒有任何依賴關係的實體，您可以簡單地使用新建立一個實例。
如果它們具有依賴關係並且必須由IoC容器創建，並且在啓動時無法完成，那麼您將需要使用工廠接口。此工廠接口包含一個CreateRefund方法，該方法將所有必需的參數傳遞給創建的實例。該接口在其使用者的命名空間/程序集中定義。
該接口的實現取決於IoC容器。一些容器提供了接口由容器自動實現的功能，只需在配置中指定它即可。其他像Unity一樣需要手動執行。此實現位於組合根中，作爲容器配置的一部分。讓實現獲取容器的實例並使用它創建請求的Refund實例。
這樣，您訪問容器的唯一位置在Composition Root中。
謝謝你的回答。我有一個基於上面說過的問題...我應該總是使用一個服務，而服務又使用一個存儲庫，而不是直接使用任何存儲庫？ – inthegarden
@inthegarden：您無法直接在服務的皮膚上公開存儲庫，也無法直接將實體返回到UI。所以在你的應用程序的頂層，你需要*某種類型的圖層。如果這完全映射到外部可調用的服務層，那很好。但是我不會將所有服務鉤子插入到該層的所有內容中*除非我想將UI上的每一項功能都公開給調用Web服務的人。這項服務是一套獨立於用戶界面的需求，所以不要過分熱衷於讓所有事情都通過它。 –