单用户单沙龙评分校验逻辑应置于哪一层？策略是否适用？

校验逻辑的最佳放置层级 #

• 业务逻辑层（Service层）：这是最适合的位置。"单个用户仅能对同一家沙龙提交一次评分"属于核心业务规则，和评分创建的核心逻辑强绑定。放在Service层能确保无论通过什么入口（API接口、内部服务调用、后台任务等）创建评分，都会触发该校验，避免规则被绕过。
  示例逻辑：在创建评分的服务方法中，先查询数据库确认当前用户是否已对目标沙龙提交过评分，若存在则抛出业务异常（比如DuplicateRatingException），不存在再执行评分插入操作。

• 控制器层（Controller层）：不推荐。虽然可以在接口入参后快速做校验，但这种方式只能覆盖API请求这单一入口，一旦有其他调用评分创建逻辑的渠道，就会跳过该校验，导致业务规则失效。

Policy（策略）的适用场景 #

Policy通常仅用于授权校验，比如判断当前用户是否具备提交评分的基础权限（是否已登录、是否属于沙龙允许评分的用户群体等），并不适合用来处理业务规则类的校验。
把业务规则塞进Policy会混淆职责，让Policy变得臃肿，违背单一职责原则。而且Policy一般是针对请求的前置授权判断，和业务逻辑的执行生命周期不匹配，无法很好地和评分创建的核心流程联动。

兜底保障建议 #

为了避免并发场景下的竞态问题（比如两个请求同时通过业务层校验，同时插入数据），建议在数据库层面给用户ID和沙龙ID字段添加联合唯一索引。这样即使业务层校验出现疏漏，数据库也会直接抛出唯一约束冲突的错误，从底层保证数据的一致性。

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