清洁架构REST服务中更新用例的领域规则落地问题

核心原则是不能绕过领域实体A执行业务规则，所有领域级约束必须由领域层的实体A自身处理，具体方案如下：

1. 明确各层模型职责 #

• 更新请求模型：属于用例层/接口适配层，仅包含应用特定的输入格式（可选字段），只做应用级校验（如字段格式、非业务性必填校验），不承载领域规则。
• 领域实体A：唯一承载所有固有业务规则（如年龄与出生日期的约束），任何字段修改必须通过实体的方法触发内部校验。

2. 用例层的更新流程 #

• 步骤1：加载完整实体
  用例层接收更新请求后，首先调用数据访问端口，根据请求中的标识（如ID）加载当前存储的完整实体A实例。
• 步骤2：增量更新实体字段
  用例层将更新请求中的非空字段映射到已加载的实体A实例上——可以通过手动判断字段是否存在值、或使用映射工具（如MapStruct）实现增量赋值。
  注意：必须通过实体A的公开方法修改字段（如setBirthDate(Date date)），而不是直接修改私有属性，确保字段修改时自动触发实体内部的业务规则校验。
• 步骤3：触发领域规则校验
  如果实体的字段Setter方法未自动校验规则，可在更新完成后调用实体的validate()方法，强制触发所有领域约束检查。若校验失败，用例层抛出领域异常，终止更新流程。
• 步骤4：持久化更新后的实体
  用例层调用数据访问端口的更新方法，传入完整的、已校验的实体A实例，由基础设施层完成持久化操作。

3. 修正数据访问端口设计 #

之前让数据访问端口接收更新请求模型的做法不符合清洁架构原则，正确的设计是：

• 数据访问端口的更新方法应接收领域实体A作为参数，而非应用特定的更新请求模型。
• 若需要优化数据库操作（如仅更新修改过的字段），可在基础设施层实现数据访问端口时，对比实体的原始状态与更新后的状态，生成增量SQL语句，但这属于基础设施层的优化细节，不影响领域层的规则执行。

补充说明 #

• 不要将更新请求模型放入领域层：更新请求是应用特定的输入格式，属于外部适配层范畴，放入领域层会污染领域模型的纯粹性。
• 性能优化方案：若加载完整实体的开销过大，可在实体内部提供细粒度的更新方法（如updateAge(int newAge)），用例层根据请求字段调用对应方法，精准触发相关规则，同时减少不必要的字段加载（但仍需保证实体状态的完整性）。

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