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。

通过包含权限列表的角色来表达用户权限。每个方法都会传递发件人并检查方法内部的访问权限。这也允许轻松测试访问权限。