Spring Boot命令模式实现：传对象还是ID的最佳实践咨询

针对你提出的两种实现思路，我们可以从职责单一性、代码复用性、维护成本、事务一致性几个维度逐一分析，再给出适配不同场景的决策建议：

方案一：传递已获取的Person/Child对象（当前实现） #

优势 #

1. 严格遵循单一职责原则：AddChildToPersonCommand只专注于「关联人员与子项并持久化」的核心逻辑，不需要关心对象的查询、权限校验、缓存读取等前置操作，边界清晰，后续修改关联逻辑时不会影响查询逻辑。
2. 复用通用查询逻辑：GetPersonByIdCommand和GetChildByIdCommand可以封装统一的查询规则（比如缓存命中判断、权限拦截、字段过滤），所有需要获取对象的场景都能复用，避免重复造轮子。
3. 扩展性更强：如果后续需要从非数据库渠道获取对象（比如Redis缓存、外部用户中心API），只需要修改对应的查询命令，业务命令完全不需要改动。

劣势 #

• 服务层代码冗余：复杂业务场景下，Service方法需要先调用多个查询命令获取对象，再调用业务命令，代码会显得冗长。

方案二：传递ID，由AddChildToPersonCommand自行查询 #

优势 #

1. 服务层代码简洁：Service只需要调用一个命令并传入ID，无需关心中间的查询步骤，代码更紧凑。
2. 事务内一致性更高：查询和关联操作在同一个命令的执行流程中，更容易保证在同一个事务上下文里，降低多线程并发下的脏数据风险。

劣势 #

1. 职责膨胀，违反SRP：命令既要处理查询又要处理业务逻辑，后续如果查询规则变更（比如新增权限校验），所有类似的命令都需要修改，维护成本陡增。
2. 重复代码泛滥：每个业务命令都要重复编写查询逻辑，无法复用通用规则，代码冗余度高。
3. 测试复杂度提升：测试业务命令时，需要同时模拟查询逻辑和业务逻辑，测试用例的复杂度会增加。

最优决策建议 #

优先选择方案一，同时解决服务层冗余问题 #

方案一的架构更符合设计原则，长期维护成本更低。针对服务层代码冗长的问题，可以通过组合命令来优化：

创建一个组合命令封装查询+业务逻辑的完整流程，Service直接调用这个组合命令即可：

@RequiredArgsConstructor
public class AddChildToPersonCompositeCommand implements Command {
    private final CommandFactory commandFactory;
    private final Long personId;
    private final Long childId;

    @Override
    public Person execute() {
        // 内部复用已有的查询命令
        Person person = (Person) commandFactory.create(GET_PERSON_BY_ID, personId).execute();
        Child child = (Child) commandFactory.create(GET_CHILD_BY_ID, childId).execute();
        // 调用核心业务命令
        return (Person) commandFactory.create(ADD_CHILD_TO_PERSON, person, child).execute();
    }
}

优化后的Service代码会非常简洁：

public Person addChildToPerson(Long personId, Long childId) {
    return (Person) commandFactory.create(ADD_CHILD_TO_PERSON_COMPOSITE, personId, childId).execute();
}

特殊场景下的方案二优化 #

如果你的业务场景对事务一致性要求极高（比如高并发写场景），可以考虑方案二，但必须抽离通用查询逻辑，避免代码冗余：

1. 先封装一个通用查询服务，统一处理对象的查询规则：

@Service
public class EntityQueryService {
    private final PersonRepository personRepository;
    private final ChildRepository childRepository;

    public Person getPersonById(Long id) {
        // 统一实现缓存、权限校验、异常处理等逻辑
        return personRepository.findById(id)
                .orElseThrow(() -> new RuntimeException("Person not found"));
    }

    public Child getChildById(Long id) {
        return childRepository.findById(id)
                .orElseThrow(() -> new RuntimeException("Child not found"));
    }
}

2. 业务命令注入该查询服务，复用查询逻辑：

@RequiredArgsConstructor
public class AddChildToPersonCommand implements Command {
    private final EntityQueryService queryService;
    private final PersonRepository personRepository;
    private final Long personId;
    private final Long childId;

    @Override
    public Person execute() {
        Person person = queryService.getPersonById(personId);
        Child child = queryService.getChildById(childId);
        // 执行关联逻辑
        person.getChildren().add(child);
        return personRepository.save(person);
    }
}

额外注意事项 #

• 事务管理：无论选择哪种方案，都要确保整个业务流程在同一个事务中执行（比如在Service方法或组合命令上添加@Transactional注解），避免数据不一致。
• 幂等性：如果是分布式场景，传递ID的方案更容易实现幂等（通过ID唯一标识操作），可以根据业务需求做针对性设计。
• 测试友好性：方案一的测试更简单，只需要Mock传入的对象即可；方案二需要Mock查询服务或Repository，测试用例要覆盖更多场景。

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