遵循整洁架构时，账户创建的数据库层逻辑处理与并发一致性问题

我正在实现一个允许参与者创建账户的用例，在User类中编写了以下方法：

async createUser({ email, username, password }: Pick<UserObject, 'password' | 'email' | 'username'>) {
  return await this.#dbAccessor.createNewUser({ email, username, password });
}

//and...
checkEmailExists(email: string): boolean;
checkUsernameExists(username: string): boolean;

在**用例层（Use-Case Layer）**中，执行流程为：

• 通过密码哈希、格式校验等工具完成前置检查
• 调用checkEmailExists和checkUsernameExists验证邮箱/用户名未被占用
• 验证通过后执行createUser创建用户

核心疑问 #

• 若从检查完成到执行插入操作期间，邮箱/用户名的检查结果因其他请求修改而失效，该如何处理？
• 为避免这种情况，是否需要将检查逻辑迁移到数据库查询中？是否会导致应用/企业逻辑泄漏到适配器层？
• 在数据库层实现类似checkAndInsertNewUser的原子方法是否更适合该场景？

1. 竞态条件的根本解决思路 #

你遇到的是典型的分布式系统竞态条件问题——应用层的检查与插入是两个独立的数据库操作，中间存在时间窗口，完全可能被其他请求修改数据状态，导致检查结果失效。

靠应用层的串行检查无法彻底避免这个问题，唯一可靠的方式是将「检查唯一性+插入用户」合并为原子操作，而实现原子性的最佳位置就是数据库层。

2. 迁移检查逻辑到数据库不会导致逻辑泄漏 #

这里需要明确职责边界：

• 纯业务逻辑（比如密码强度要求、用户名格式规则、用户角色校验等）属于企业规则，必须留在用例层；
• 数据唯一性约束是数据本身的完整性要求，属于数据库的核心职责——数据库本来就应该保证数据的一致性和完整性，这不属于逻辑泄漏。

你可以先在数据库层面给email和username字段添加唯一索引，这样即使应用层跳过检查直接插入，数据库也会抛出重复键错误，从底层阻断重复数据的产生。

3. 数据库层实现原子创建方法是最优方案 #

非常推荐在数据库层（或DAO适配器层）实现checkAndInsertNewUser这类原子方法：

• 对于关系型数据库，可直接利用原生语法实现原子操作：比如MySQL的INSERT ... ON DUPLICATE KEY UPDATE、PostgreSQL的INSERT ... ON CONFLICT DO NOTHING，把检查和插入合并成一条SQL，天然具备原子性；
• 如果用DAO层封装，可将检查与插入放在同一个数据库事务中，确保整个操作的原子性，避免中间状态被其他请求干扰。

最终推荐流程 #

1. 用例层保留前置业务检查：负责密码哈希、格式校验、长度限制等企业规则验证；
2. 移除用例层的checkEmailExists/checkUsernameExists调用；
3. 直接调用数据库层的原子创建方法（或带唯一约束的插入语句）；
4. 捕获数据库抛出的「唯一键冲突」异常，转换成用户友好的应用层错误（如“邮箱已被注册”）返回。

这种方式既保证了数据唯一性，又清晰划分了各层职责，同时彻底解决了竞态条件问题。

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