在DDD中處理嵌套聚合

我剛剛開始使用DDD，並且在確定如何適應數據的關係性質時遇到了一些麻煩。我有我認爲會被認爲是我的總根，但總計也有自己的總和。不想違反德米特法，我想知道我是否在考慮這個錯誤，並希望有些DDD專家能夠提供一些見解。在DDD中處理嵌套聚合

我的聚合根是我的Account對象，它具有多個AccountElement實體的聚合，它們本身是各個ProductComponent實體的邏輯分組。

的AccountElement外的Account的背景下是沒有意義的，所以我很舒服，我的結論是，Account對象是我聚合根，我預計其總Elements物業實體。這是ProductComponent集合，讓我感到困惑。這個聚合在AccountElement以外沒有意義，而真的在Account之外沒有意義。

我不認爲我應該打點自己的路吧，等來訪問個人ProductComponent對象：

var reference = account.Elements(0).ProductComponents(0).ReferenceCode;

但在同一時間，它沒有任何意義（從域角度看）將直接從Account實體訪問ProductComponent。

我敢肯定，如果沒有我的域名知識，這是一點點難以理解，但我希望這足以得到一些好的反饋。

來源

2010-02-05 Josh Anderson

如果你需要這個級別的嵌套對象來使你的對象模型工作，那麼我不會太擔心得墨忒耳定律。見http://haacked.com/archive/2009/07/14/law-of-demeter-dot-counting.aspx – 2010-02-05 22:37:36

另請參見http://www.dcmanges.com/blog/37 – 2010-02-06 01:41:32

謝謝，菲爾的文章是有幫助的，以及兒童的孩子與聚合根源之間如何不可分割地相關的問題在這裏非常關鍵。考慮到這一點，嵌套這些實體纔有意義。我更舒服，這是正確的，因爲在作出這個決定後，代碼的方向似乎更加直觀。或在DDD的精神，我可能會更好說它是無處不在的語言更真實的抽象;） – 2010-02-08 19:51:27

羅伯特連接的文章是一個很好的。我會補充說，如果ProductComponent僅存在於AccountElement的上下文中，並且AccountElement僅存在於Account的上下文中，則通過擴展ProductComponent在Account的上下文中。

來源

2010-02-05 22:56:49

在DDD中處理嵌套聚合

回答

相關問題