DDD中实体之间的关系

Question

6

我是DDD的初学者，尝试在小而简单的领域中工作，以便掌握所有设计原则。

我有一个简单的领域：机构(Institution)及其可用的WiFi热点(Place)存储在数据库中。没有机构就不能存在任何地方。机构有管理员用户-受托人(User)，其具有添加新地点、重新分配或删除现有地点的权利。

代码可以在这里找到。暂时放弃了值对象的验证。

这是正确的DDD设计吗？或者至少接近它吗？

虽然我是一名数据中心的程序员，但我仍然想知道如果通过聚合根访问聚合是一种经验法则，那么我将如何列出所有机构的所有地点呢？

在实体本身(Place::create)内部生成Uuid的想法好吗？

只有被委托人(User)可以添加/删除地点的想法应该在域本身表达，还是应该由客户端负责？在这种情况下，如果受托人知道他管理的机构(institutionId in User?)，那将是明智的。

Institution::placeById有没有违反DDD的原则？也许这是仓储的责任？

- andrius.k

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Christian Johansen · Accepted Answer

聚合根规则仅适用于写入侧。如果有专门的读取模型，则此问题将消失。您应该可以自由投影到适合您用户场景的读取模型。

否则，您可以将所有机构位置添加到哈希集中并返回平面列表。

在设计聚合根时，请考虑更新方案。地点是否可以独立于机构进行更新？如果是，则它可能是自己的聚合根。

通常存储库应确定下一个ID。

通过包含权限列表的角色表达用户权限。在每种方法中传递发送者并检查访问权限。这也允许轻松测试访问权限。