领域驱动设计：聚合根创建的实现疑问与技术咨询

问题1：校验“仅管理员可创建排行榜”规则的最佳位置 #

把校验放在Administrator类的createLeaderboard方法里是完全合理的，甚至是更符合DDD原则的选择。

原因很明确：

• 这条规则的核心是「谁有资格发起创建动作」，属于操作发起者（管理员）的权限约束，而非排行榜自身的状态约束。Leaderboard的构造函数只需要负责保证自身内部状态合法（比如名称不能为空、分数规则有效这类自身不变量），没必要关心“谁创建了我”。
• 按照Udi Dahan的观点，聚合根不能凭空创建，必须由其他聚合根生成。通过管理员的方法创建排行榜，刚好能强制这条规则——你没法绕过管理员直接调用Leaderboard的构造函数来创建实例，从根源上避免违反“仅管理员可创建”的领域规则。

如果把校验放在Leaderboard的构造函数里，反而会让聚合根承担不属于它的职责，而且没法阻止外部直接调用构造函数绕过校验（哪怕把构造函数设为私有，逻辑上也不该由被创建的聚合根来校验创建者权限）。

问题2：由排行榜发布创建事件是否可行？算不算反模式？ #

这种方式完全可行，不是反模式，反而贴合DDD中领域事件的设计原则。

• 领域事件是用来描述聚合根状态变化的，LeaderboardCreatedEvent本质是“排行榜被创建”这个状态变更的记录，这个事件属于Leaderboard聚合根，理应由它自己发布。管理员只是发起了创建动作，但事件的产生是因为Leaderboard的状态发生了初始变化，所以由Leaderboard来发布事件才是合理的。
• 执行操作的实体（管理员）不需要负责发布目标聚合根的事件。管理员的职责是“发起创建排行榜的动作”，而排行榜的职责是“记录自己的创建事件”，两者职责划分清晰，符合单一职责原则。

举个实际代码逻辑的例子：管理员调用createLeaderboard方法，方法内部先校验自身权限（比如确认是活跃管理员），然后创建Leaderboard实例，Leaderboard在初始化过程中发布LeaderboardCreatedEvent，最后管理员返回实例或交由仓储持久化。整个流程里，每个聚合根只处理自己的职责，边界清晰。

内容的提问来源于stack exchange，提问作者alaboudi