適用於域驅動設計原則的最佳實踐？

Question

域驅動設計有時會讓人感到困惑，因爲我對這項技術頗爲陌生，所以我想針對那些正在困擾我的場景做一些解答。

這裏用一個簡單的圖來表示我的問題使用DDD的原則。我的問題是關於聚合根，域驗證和「做法」或最佳實踐。

1. 在這種情況下，您將如何實現一種方法來計算用戶寫入的評論數量？它會成爲「評論」中的一種方法嗎？或者最好是存儲庫中的方法（ReviewRepository）？
2. 如何讓其他實體在需要時訪問評論？有了這種情況，這是否意味着評論不再是「評論」總量的一部分？
3. 如果評論與其他實體有構成關係怎麼辦？你將如何管理對該實體的訪問？評論是否對這個實體或根源負責？
4. 有關此型號的其他建議或事實？在設計模型時，我應該與其他任何最佳實踐一起？

謝謝。

注意：答案一定同胞DDD原則

在有審查實體一點錯誤。 Add方法中的「Compte」是「Account」，應該是A而不是C.

Answer 1

在這種情況下，您將如何實現一種方法來計算用戶寫入的評論數量？

責任歸屬於審查。這是一個評論彙總。 Count是任何聚合的頭等功能。

如何讓其他實體訪問評論，如果他們需要？

評論通過審查可訪問。評論是評論的彙總。

如果評論與其他實體有構圖關係怎麼辦？

如果沒有具體的具體例子，「假如」的問題很難回答。畢竟，設計是由問題領域驅動的，而不是隨機的想法。

如果某些「其他」實體似乎也是評論的組成部分，則必須返回到域專家並嘗試確定責任所在的位置。

一對問題是「如果評論被刪除，評論會發生什麼？」和「如果神祕的'其他'被刪除，評論會發生什麼？」這可以幫助找到責任。