如果只有本地到数据库层的逻辑不能放入实体方法，那么我如何遵循干净的体系结构风格呢？

Question

对于允许参与者执行帐户创建的用例。

因此，我在用户上创建了这些方法

 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;

在用例层，在克服了与实用程序(如pwhashing和验证)检查的障碍之后，我使用checkEmailExists和checkUsernameExists创建了使用检查条件，如果通过，我将最终运行createUser。

然而，我的问题是，如果这些电子邮件/用户名检查在开始插入时已经过时了怎么办？为了防止这种情况，我必须将这些检查逻辑迁移到db查询中吗？如果是这样的话，这不意味着我的逻辑正在从应用程序逻辑/企业逻辑层泄漏到这些适配器中吗？

在这个场景中，像'checkAndInsertNewUser‘这样的方法是否更合适，并在数据库层实现呢？

Answer 1

通常不建议将业务逻辑与数据库层“合并”。如果您希望或需要在某个时候替换整个数据库层，怎么办？如何测试独立于数据库的业务逻辑(决策制定)？即使您的业务逻辑涉及查询数据库，实际的决策(检查什么以及如何检查)也应该与数据库分开。在您的情况下，可能有用的，甚至必要的是使DB的查询和新项的创建/插入成为原子的事务。