域驅動設計：對其成員的聚合禁止引用

遵循DDD規則，聚合不應允許外部對象持有對其成員的引用。域驅動設計：對其成員的聚合禁止引用

如果聚合「發票」是封裝發票和它的詳細信息。彙總發票應該如何提供信息，以便我可以顯示詳細信息或生成報告？

2012-07-27 Pleonc

DDD的原則傾向於在CQRS也處於有序狀態的協作域中最爲有效。因此，用於更新的相同域模型的報告會非常混亂。 – 2012-07-27 14:17:17

在DDD的上下文中，持有引用意味着某種數據庫引用。這並不意味着一旦你從數據庫加載你的聚集，沒有任何東西可以獲得對其任何成員的運行時引用。這個想法是，與聚合成員的所有交互都通過聚合，從而履行其作爲一致性和完整性邊界的角色。但是，爲了顯示和查詢目的，我更喜歡read-model pattern，其中查詢特定類用於表示查詢數據，並且不同於用於表示聚合的類。這允許聚合集中在其行爲上，而不用關心它可能是什麼查詢。如果使用CQRS + Event Sourcing，那麼你聚合沒有公共數據成員，只有行爲方法。在這種情況下，查詢將根據聚合生成的事件實施爲預測。

來源

2012-07-27 17:10:00 eulerfx

謝謝eulerfx。雖然你指的是一個很好的解決方案，但我認爲它不僅僅是避免數據庫引用，而且也是運行時引用。正如你所說的，這個想法是，所有與聚合成員的交互都通過聚合，從而實現其作爲一致性和完整性邊界的角色。如果我提供了一個內部實體的參考，並且有公共制定者，那麼我會打破這個模型。 – Pleonc 2012-07-27 18:00:05

是的，這是真的，你在這方面的嚴格程度可能會有所不同。例如，如果您使用的是諸如NHibernate之類的ORM，它需要公共成員進行映射，因此您別無選擇，只能將該選項留給外部引用。 – eulerfx 2012-07-27 19:46:32

數據庫引用或詳細信息（如ORM）在域中沒有位置。這就是爲什麼你開始對IGNORING數據庫進行建模的原因，這樣你就不會試圖建立一切以db爲中心的東西。 CQRS是這個問題最明顯，最簡單和可維護的解決方案。 – MikeSW 2012-07-28 08:36:01

我允許客戶端持有對值對象的引用。我沒有恐懼地返回VO的。我也將VO傳遞給Aggregate Root上的公共方法。值對象是不可改變的，因此不存在違反聚合的一致性邊界的外部狀態改變的危險。

來源

2015-03-06 01:53:42 Seph

域驅動設計：對其成員的聚合禁止引用

回答

相關問題