DDD中的實體之間的關係

Question

我是DDD的初學者，圍繞小而簡單的領域工作，以便讓我掌握所有設計原理。

我有這個簡單的域名：機構（Institution）和他們的可用WiFi點（Place）保存在數據庫中。沒有機構就沒有地方可以存在。機構有經理用戶 - 受讓人（User），有權增加新的地方，重新分配或刪除現有的地方。

Code can be found here。目前，對值對象的驗證仍然存在。

這受Mathias Verraes on child entities的影響。

這是一個正確的DDD設計？或者至少靠近它？

作爲一個以數據爲中心的程序員，我仍然想知道如果經驗法則是通過聚合根訪問聚合，我將如何列出所有機構的所有地方？

生成Uuid的想法是在實體本身內部（Place::create）好嗎？

應該有一個想法，只有受讓人（User）可以添加/刪除的地方表達在域本身或應該是客戶的責任？在這種情況下，如果受讓人知道他的受控機構（institutionId在User？），這將是明智的。

難道Institution::placeById違背DDD的任何原則嗎？也許這是版本庫的責任？

Answer 1

聚合根規則僅適用於寫入端。如果有專門的讀取模型，此問題將消失。您可以自由投影以閱讀適合您用戶場景的模型。

否則你可以添加機構的所有地方哈希設置返回展平列表。

當取消指定聚合根時，請考慮更新方案。可以獨立於機構更新地點嗎？如是。那麼它可能是它自己的一個聚合根。

通常存儲庫應該確定下一個ID。

通過包含權限列表的角色來表達用戶權限。每個方法都會傳遞發件人並檢查方法內部的訪問權限。這也允許輕鬆測試訪問權限。