CQRS架构规范是否禁止在同一控制器动作中同时使用查询与命令？

首先直接给结论：CQRS并没有硬性规范禁止在同一个控制器动作内先后执行查询（Query）和命令（Command），它的核心是「分离读操作和写操作的职责」，而非完全割裂两者在业务流程中的配合。

CQRS的核心原则回顾 #

CQRS的本质是将系统的**读逻辑（Query）和写逻辑（Command）**拆分开：

• Query仅负责读取数据，不修改任何系统状态，可返回业务数据
• Command仅负责修改系统状态，不应该返回业务数据（最多返回执行成功/失败的标识）

它的目标是优化读/写各自的性能、复杂度和扩展性，比如让读模型可以针对性做缓存、分库分表，写模型专注于业务规则和事务一致性。

你的场景完全符合CQRS规则 #

你代码里的「先查询确认帖子存在，再执行删除命令」的逻辑，是非常典型的业务流程处理方式，完全符合CQRS的设计思想：

• GetPostByIdQuery是纯查询，只做数据读取，没有任何状态变更
• DeletePostCommand是纯命令，只负责删除操作，不返回业务数据
• 两者的职责依然严格分离，只是在控制器层（Web入口）组合成了一个完整的用户请求流程

你的代码实现：

[ApiController]
public class PostsController : ControllerBase
{
    [HttpDelete("/posts/{postId}")]
    public async Task<IActionResult> DeletePost(Guid postId)
    {
        var postDTO = await _mediator.Send(new GetPostByIdQuery(postId)); // 查询
        if (postDTO == null)
        {
            return NotFound();
        }
        await _mediator.Send(new DeletePostCommand(postId)); // 命令
        return NoContent();
    }
}

额外的小建议（和CQRS无关，是并发场景优化） #

需要注意的是，在高并发场景下，可能会出现「你查询到帖子存在，但执行删除命令时，帖子已经被其他请求删除」的竞态问题。所以建议在DeletePostCommand的处理逻辑内部也做一次存在性校验，这样能保证业务逻辑的健壮性，但这不属于CQRS的规则要求，只是业务容错的优化。

总结 #

你的这种实现方式没有违反CQRS的任何规则，控制器作为请求入口，负责协调查询和命令来完成完整的业务流程，是完全合理的实践方式。

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