CQRS模式下命令类依赖查询类是否合规？求更优实现方案

问题描述 #

我在NestJS项目中按CQRS模式拆分命令与查询服务，部分命令方法需调用查询类的方法，于是在命令类的构造函数中注入了SalonServicesQuery实例，示例代码如下：

// command.ts
constructor(
    //...imports repos

    private salonServicesQuery: SalonServicesQuery // 注入查询类实例
  ) {
    //
  }

async updateService(serviceId: number, salonId: number, dto: UpdateServiceDto) {
    // 前置校验逻辑

    const service = await this.salonServicesQuery.getById(serviceId, salonId); // 调用查询类的方法

    let category: any;
    if (dto.categoryId) {
      category = await this.categoryRepository.findOne({
        where: { id: dto.categoryId, salon: { id: salonId } },
      });

      if (!category) {
        throw new NotFoundException(
          `Category with ID '${dto.categoryId}' not found in salon '${salonId}'`
        );
      }
    }
   // 后续业务逻辑处理
}

目前因环境问题尚未运行程序，但VSCode无语法报错。现咨询：这种拆分方式是否正确？有无更合理的实现思路或优化方案？

回答 #

1. 当前实现的合理性 #

这种做法不算严格符合CQRS的纯粹设计原则，但在实际项目开发中是可接受的折中方案：

• CQRS的核心是「读写分离」，命令侧负责修改系统状态，查询侧负责读取状态；纯粹的CQRS设计中，命令类应直接操作领域模型或底层仓储，避免依赖查询类，以保持职责单一。
• 但实际开发中，为了复用已有的查询逻辑（比如复杂的过滤、关联查询），直接注入查询类是常见的简化手段，只要不出现循环依赖、事务边界清晰，语法和运行层面不会有问题。

2. 优化方案 #

（1）直接操作仓储（推荐简单场景）

如果查询逻辑简单（比如仅根据ID查询实体），命令类可以直接注入对应的Repository，跳过查询类，更贴合CQRS的职责划分：

// 修改后的command.ts构造函数
constructor(
    private salonServiceRepository: SalonServiceRepository,
    private categoryRepository: CategoryRepository
  ) {}

async updateService(serviceId: number, salonId: number, dto: UpdateServiceDto) {
    const service = await this.salonServiceRepository.findOne({
      where: { id: serviceId, salon: { id: salonId } }
    });
    if (!service) {
      throw new NotFoundException(`Service with ID '${serviceId}' not found`);
    }
    // 后续逻辑...
}

（2）封装领域服务（推荐复杂场景）

如果查询逻辑复杂、需要跨多个仓储或包含业务规则判断，可以封装一个独立的领域服务类，把查询和命令相关的复用逻辑放在里面，命令类仅调用领域服务：

// salon.service.ts（领域服务）
@Injectable()
export class SalonService {
  constructor(
    private salonServiceRepository: SalonServiceRepository,
    private categoryRepository: CategoryRepository
  ) {}

  async getSalonServiceById(serviceId: number, salonId: number) {
    return this.salonServiceRepository.findOne({
      where: { id: serviceId, salon: { id: salonId } }
    });
  }

  async getSalonCategoryById(categoryId: number, salonId: number) {
    return this.categoryRepository.findOne({
      where: { id: categoryId, salon: { id: salonId } }
    });
  }
}

// 修改后的command.ts
constructor(private salonService: SalonService) {}

async updateService(serviceId: number, salonId: number, dto: UpdateServiceDto) {
    const service = await this.salonService.getSalonServiceById(serviceId, salonId);
    if (!service) {
      throw new NotFoundException(...);
    }
    // 后续逻辑...
}

（3）事件驱动（适合最终一致性场景）

如果业务允许最终一致性，可以在命令执行完成后发布领域事件，查询侧通过监听事件更新查询视图（比如读写分离的数据库视图）。这种方式完全遵循CQRS的读写分离原则，但需要额外处理事件订阅和视图更新逻辑，适合高并发、实时性要求不高的场景。

（4）确保事务边界清晰

如果命令中同时包含查询和修改操作，要确保所有操作在同一个事务内执行，避免数据不一致。比如使用TypeORM的@Transactional装饰器：

@Transactional()
async updateService(serviceId: number, salonId: number, dto: UpdateServiceDto) {
    // 查询逻辑
    // 修改逻辑
}

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