DDD中聚合根重复值校验应放在领域层还是应用层？

核心认知前提 #

不要被"所有领域逻辑必须封装在聚合根/领域服务内"的教条束缚：全局唯一约束本质是跨全量聚合的校验规则，天然不可能在单个聚合根内部完成，判断逻辑放哪一层，核心看逻辑本身的职责属性，而非生硬套分层规则。

常见实现方案对比 #

1. 应用服务层实现校验（绝大多数场景的最优选择） #

你最终选择的这个方案完全合理，不存在违反DDD原则的问题：

• 应用服务的核心职责就是协调仓储、领域对象、基础设施组件完成完整业务用例，"创建用户前检查用户名是否已存在"属于用例执行流程中的前置协调步骤，不属于需要封装在聚合内部的核心不变量。
• 不需要额外封装领域服务做这层校验：领域服务的适用场景是逻辑需要协调多个同领域的聚合、或者包含核心领域计算规则，单纯的"查仓储判断是否存在"的逻辑没有额外的领域语义，强行封装只会增加无意义的分层跳转，提升代码复杂度。
• 注意区分规则定义和规则执行："用户名不允许重复"这个领域规则本身属于领域层（比如你定义的DuplicateUsernameException、Username值对象内的格式校验逻辑都应该放在领域层），但执行"查询全量数据判断是否重复"的动作，完全可以放在应用层做协调。

你贴的示例代码有一个小bug：rename方法里的相等判断逻辑有误，原代码!username.equals(username)永远为false，不会触发更新，修正后的代码如下：

// 修正后的rename方法
public void rename(Username newUsername) {
    if (!this.username.equals(newUsername)) {
        this.username = newUsername;
        EventBus.raise(new UserRenamedEvent(newUsername));
    }
}

2. 必须做的兜底：数据库唯一索引 #

不管你在哪一层做前置校验，都必须给数据库的用户名字段加唯一约束：应用层的查询校验存在并发竞态问题——两个携带相同用户名的创建请求同时到达，都通过了前置的findByName检查，最终依然会插入重复数据。数据库唯一索引是最后一道防线，捕获到索引冲突异常后，将其转换为领域层定义的DuplicateUsernameException抛出即可。

3. 分布式场景特殊处理 #

如果是跨服务的分布式架构，无法依赖单机数据库的唯一索引，可以提前生成用户名对应的唯一占位记录，通过分布式锁、唯一令牌占坑的方式避免并发重复，这类协调逻辑同样放在应用服务层实现即可。

总结 #

DDD分层的核心目的是隔离核心业务逻辑和基础设施细节，降低核心逻辑的维护成本，而非追求形式上的分层纯粹性。只要核心领域规则的定义放在领域层，类似全局唯一性校验这类需要访问全量数据的协调逻辑，放在应用服务层是性价比最高、最易维护的实现方式。

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