DDD存儲庫對其他存儲庫的瞭解

Question

一個存儲庫可以訪問另一個存儲庫通常是可以接受的嗎？特別是在這種情況下，我有一個聚合根使用另一個聚合根來確定要添加的實體。它落在一個項目/項目類型關係的線上。 Item Type是一個聚合根的原因是它們可以在任何單個項目範圍之外的管理工具中單獨維護。

如果事情果真如此，我也只能通過倉庫工廠實現創建我的庫實例，所以我並沒有直接通過具體的類名創建它。任何時候都不知道存儲庫。

編輯 - 更多信息：

的具體實施是，我們可以將圖像文件。我們不僅可以管理文檔上的圖像，還可以使用不同類型的圖像（例如，類型被定義爲如何實現，而不是擴展名）。文檔聚合是系統中使用這些圖像的幾種其他對象之一，並且它們不都使用相同的類型。雖然我們在域服務中附加了規則，但這更具體地針對構建文檔聚合。在構建聚合時，我們有五個特定類型的圖像，以及另外兩種類型的圖像。我們將這些單獨存儲在單獨的列表中。驗證不是問題，但限制組裝文檔時正在評估哪種類型的圖像。

Answer 1

我想這歸結於你想要做的事情。如果它是一種驗證步驟（例如，刪除所有物品類型已過期的所有物品），您可能會認爲它屬於服務層或規範。從你使用的語言（即「確定要添加什麼實體」），它似乎暗示了後者，儘管沒有更多細節很難說。

我想從某個角度來看，沒有真正的原因，爲什麼你不能（我決不是一個超級DDD最純粹的），特別是因爲一個項目及其類型可以被視爲一個聚合根，它是隻有您需要提供防止的管理控制檯的實施細節。

從另一個角度來看，它確實表明，有你的總根源，可以提出兩種不同的情況下都在工作之間的模糊。例如，有人可能會爭辯說，管理工具爲主應用程序形成了一個單獨的有界上下文，因此Item類型作爲聚合根的情況並不適用。例如管理工具可能只涉及項目類型（而不是項目），而主應用程序可能會將項目類型視爲比實體更多的值對象。

更新

你提到組裝這似乎是一個工廠類，能正確安裝一個有效的實體的責任的文件（工廠可以使用圖像類型庫）。一個存儲庫應該（在我的眼中）公開查詢和添加操作，而不是配置實體的邏輯（除了可能從持久化進行補充）。