我是DDD的初学者，在小型简单领域工作，以便了解所有设计原则。
我有这个简单的域：机构（User）及其可用的WiFi点（Uuid）保存在数据库中。没有机构就没有地方可以存在。机构有经理用户 - 受让人（Place::create），有权添加新地点，重新分配或删除现有地点。
Code can be found here。对价值对象的验证暂时搁置。
受Mathias Verraes on child entities的影响。
这是一个正确的DDD设计吗？或者至少接近它？
作为一名以数据为中心的程序员，我仍然想知道如果经验法则通过聚合根访问聚合，我将如何列出所有机构的所有位置？
在实体本身（User）内生成institutionId的想法是否合适？
只有受让人（User）可以添加/删除地点的想法应该在域名上表达，还是应该由客户负责？在这种情况下，如果受让人知道他的管理机构（Institution::placeById中的const）会是明智的。
int i;
// Const pointer to non-const int
const auto ip1 = &i; // int *const
++ip1; // error
*ip1 = 1; // OK
// Non-const pointer to const int
const auto* ip2 = &i; // int const*
++ip2; // OK
*ip2 = 1; // error
是不是违反了DDD的任何原则？也许这是存储库的责任？
答案 0 :(得分：2)
聚合根规则仅适用于写入端。如果有专用的读模型，这个问题就会消失。您可以自由地投影以阅读适合您的用户场景的模型。
否则，您可以将机构中的所有地点添加到哈希集中，并返回展平列表。
当对聚合根进行去密码时，请考虑更新方案。可以独立于机构更新吗？如是。然后它可能是它自己的聚合根。
通常，存储库应确定下一个ID。
通过包含权限列表的角色来表达用户权限。每个方法都会传递发件人并检查方法内的访问权限。这也可以轻松测试访问权限。