假設我有一個聚合，Ticket。 A Ticket將具有一個分配的Department和一個或多個分配的Employee。哪些對象負責維護聚合之間的引用？
當實例化一個Ticket，應該在TicketFactory負責確保一個Ticket與有效/存在Department和Employee產生的？
同樣，退役當Department或Employee，什麼是負責確保新Department或Employee被分配到Ticket，以維持其不變？負責退役的域中是否有服務？或者是否應該採用最終一致性或某種形式的事件監聽？
的TicketFactory會宣佈，爲了創建一個Ticket你需要引用既Department和Employee。它不會證實這些確實存在。調用代碼的責任是獲得適當的引用。
如果使用最終一致性，Department和Employee的退役將發佈指示停用的事件。將會有一個與Ticket關聯的處理程序，該處理程序將訂閱該事件並分配新的部門和員工或發送某種警告給任務。
看看Effective Aggregate Design瞭解更多。
我最近開始探索DDD，所以我遇到了一些你提到的問題。
我認爲TicketFactory應該總是返回驗證/正常內置Ticket實例。如果您的模型很複雜，則可以使用域服務驗證給定的Department或Employee可以連接到它，然後工廠使用它。否則，你可以把它放在工廠裏。但是從工廠出來的應該是一張合適的票。
我會說，如果只有Ticket瞭解其他兩個，使用Department和Employee回購的域服務將完成工作。如果關係是雙向的，那麼你可以利用事件採購。另外，如果它確實是一個應該在您的域模型中捕獲的事件，並且除了重新洗牌票據之外還有其他後果，您可以將其中一個處理程序附加到此事件中，以便InvalidTicketHandler。但是，如果它是一個小規模的事情，保持簡單，只需要一個域服務來維護不變量。
旁註：如果Department和/或Employee是聚集體本身，則可以內Ticket通過其標識符引用它們（例如僱員的公司ID或部門ID代碼）。通過這種方式，您可以更輕鬆地實現一致性，因爲您不會跨越不同聚合之間的一致性邊界。
1.我同意，這是一個工廠的一個定義特徵（它產生一個正確組裝的聚合體。）我感謝你的觀點;就像我現在看到的那樣，如果我添加一些關於可以將多少項目分配給員工或部門或類似項目的限制，那麼添加的域服務可能會有好處。 2.我完全不知道如何調用這樣的域名服務。 – tuespetre 2013-02-22 05:36:21
2.在退役過程中，常見的使用場景是什麼？首先，可能會有更多的服務可以實施。也許可能會有一個'EmployeeDecommissioner'服務來覆蓋員工被解僱的情況（我想其中包括其他情況）。然後你可以有一個'DepartmentDecommissioner'，當整個部門被拆除時可以使用'EmployeeDecommissioner'。 最好的辦法是向域名專家詢問正確的措辭 - 也許他們會使用 – 2013-02-24 21:04:17
_或許他們會使用......_其他一些術語（沒有完成前面的句子，對不起） – 2013-02-25 09:44:36
甲FACTORY是負責確保所有不變量滿足對象或聚合它創建;但在刪除應用於該對象之外的對象的規則之前，您應該總是三思而後行。工廠可以將不變檢查委託給產品，這通常是最好的。 [領域驅動設計：應對複雜性，在軟件的心]
A依賴於問題的類型，但是從它的外觀看起來像一個應用層功能的最佳候選，我不會去對於事件解決方案，儘管我發現它只適用於圖層之間，而不適用於同一圖層中的對象。
我不明白爲什麼一個工廠不能確保一個聚合包含有效的引用（或甚至未保證的代理）。你能解釋一下嗎？第二點對我有意義;我已經可以看到多個可能的處理程序，用於退役員工（向其他員工發送電子郵件，將工單移動到隊列池，更新目錄）。 – tuespetre 2013-02-22 05:14:15
另外，感謝您的鏈接 - 我已閱讀了一些文章從埃文斯埃文斯的書本壘板開始。謝謝你提醒他們，第二個特別提醒一些事情，儘管我不確定我是否同意使用全局id而不是對象引用（即使只是一個虛擬代理）。我將很快需要閱讀Evans '再次預訂，看看我是否拿起別的東西。 – tuespetre 2013-02-22 05:14:40
爲了讓工廠能夠驗證其他聚合的存在，它需要訪問其存儲庫 - 另一個依賴。由於應用程序服務已經引用了存儲庫或其他服務，它們應該負責提供適當的ID。 – eulerfx 2013-02-22 17:47:11