DDD：通過ID從其他聚合引用非根實體？

Question

我們正在使用實體框架在C＃中實現域模型的實體，以實現持久性。

從過去的經驗中汲取了一些經驗，現在我們嘗試構建小型集合體，引用Id的其他根，正如Vaugh Vernon在本文中提出的其他建議： http : //www.informit.com/articles/article.aspx? p = 2020371＆SEQNUM = 4

但是，在某些情況下，我們認為通過ID引用其他聚合中的非根實體可能會違反規則。 例如，假設下面描述的模型。 具體請參見以紅色標記的關系。

顯然，由於關系只是“按ID”，因此我們不會破壞SystemAttribute聚合的封裝。 我認為應該沒問題。 如弗農（Vernon）等人所建議的，可以將AttributeValueId定義為值對象。

現在，如果我們認為可以這種方式引用非根實體，則仍然存在問題。 要顯示給定UserGroup的所有AttributeValues（當然具有擁有的屬性）的列表，我們需要執行基於“ SELECT WHERE IN”的EF查詢，而不是僅使用聯接（如果使用實際的導航屬性引用，則可能是聯接）。 我們還可以通過EF DBContext使用Raw SQL查詢，這是因為我們在數據庫中確實有可連接的FK關系。

這里有什么想法或只是需要判斷是否可以接受的問題？

我真的很喜歡使用Id的聚合之間的“軟引用”的想法。 但這似乎並非沒有問題。

---

關於在數據庫中的多對多關系表中使用顯式實體，並決定不將此關系建立為雙向關系-分別參見Udi Dahan和Jimmy Bogard的以下文章：

https://lostechies.com/jimmybogard/2014/03/12/avoid-many-to-many-mappings-in-orms/

http://udidahan.com/2009/01/24/ddd-many-to-many-object-relational-mapping/

Answer 1

這里有什么想法或只是需要判斷是否可以接受的問題？

因此，第一個想到的想法是，您可以通過將UserGroupAttributeValue表從User Group聚合移動到System Attribute聚合來滿足規則。

tomliversidge在提出一個正確的問題-這種安排主要看起來是結構 ; 改變國家的規則是什么？ 您需要對每個更改強制執行哪些一致性保證，並且可以在有限的時間內解決？

我要補充一點：您確定在正確的位置執行ddd嗎？ 通常，進行TDD的地方是您的核心領域（您的競爭優勢所在的地方）。 否則，您可能在錯誤的箱中購物。 （注意：這更多是在戰略層面上的ddd ，而不是戰術實施模式中的下降）。