引言：从传统数据操作的局限谈起

在典型的三层应用架构中，数据访问层通常统一处理读取与写入操作，且基于相同的领域实体模型。这种设计在业务逻辑简单的系统中尚可接受，但随着系统复杂度上升、并发量增长，其弊端逐渐显现。尽管数据库层面可通过主从复制实现读写分离，若业务逻辑仍混杂在一起，则难以充分发挥性能潜力。

为此，命令查询职责分离（Command Query Responsibility Segregation, CQRS）应运而生。该模式将修改系统状态的操作（命令）与仅获取数据的操作（查询）彻底解耦，不仅提升了系统的可维护性，也为独立优化读写路径提供了可能。本文将探讨CQRS的核心理念，并通过一个简化示例展示其实现方式。

传统CRUD架构的挑战

在标准CRUD流程中，应用程序通过仓储（Repository）对实体进行增删改查操作，这些实体往往是数据库表的直接映射。虽然ORM工具能加速开发，但以下问题也随之而来：

• 粒度粗放：更新时需传递完整对象，即使只修改少数字段；查询时返回整个实体，即便前端仅需部分属性。
• 竞争与锁机制：读写共享同一资源，容易引发锁争用，影响吞吐量和响应速度。
• 性能瓶颈：高并发场景下，同步访问数据库可能导致延迟增加。
• 权限控制复杂化：同一模型承载读写语义，使得安全策略难以精细化管理。

尤其当系统读写比例失衡时（如读远多于写），这种紧耦合的设计会限制横向扩展能力。

CQRS的基本原理

CQRS源自Bertrand Meyer提出的"命令查询分离"（CQS）原则——即一个方法要么改变状态（命令），要么返回结果（查询），不可兼得。CQRS在此基础上进一步演化，主张使用不同的模型来处理读写操作：

• 命令端（Write Model）：负责处理业务逻辑、验证和状态变更，通常采用领域驱动设计（DDD）中的聚合根模式。
• 查询端（Read Model）：专注于高效地提供视图所需的数据，结构可非规范化，甚至为特定查询定制专用报表库（Reporting Database）。

两者之间通过事件进行异步通信，确保最终一致性。如下图所示，写模型产生的事件被发布到事件总线，由对应的处理器更新读模型。

适用场景分析

CQRS并非银弹，适合应用于以下情况：

• 业务规则复杂，写操作涉及大量校验和流程控制。
• 读写负载极不对称，需要独立扩展读或写能力。
• 团队希望划分职责，资深开发者专注领域建模，初级成员处理UI相关查询。
• 系统需支持历史状态回溯或审计功能，结合事件溯源（Event Sourcing）效果更佳。
• 未来可能演进为微服务架构，CQRS有助于边界清晰的服务拆分。

反之，对于简单CRUD型应用，引入CQRS反而会增加不必要的复杂性。

与事件溯源的协同作用

CQRS常与事件溯源配合使用。在该组合模式中，所有状态变更都以事件形式记录，而非直接更新实体。例如，创建日记条目不是执行INSERT语句，而是发布DiaryEntryCreatedEvent事件并持久化。读模型监听此类事件并更新自身视图存储。

这种方式带来诸多优势：

• 完整的操作审计轨迹。
• 支持任意时间点的状态重建。
• 便于调试和问题复现。

简易实现示例：在线日记系统

下面通过一个简化的日记管理系统演示CQRS的基本结构。

查询端实现

查询侧仅包含一个轻量级的数据访问接口，用于向UI提供DTO对象：

public interface IQueryStore
{
    List<DiaryEntryDto> GetAllEntries();
    DiaryEntryDto GetById(Guid id);
}

public class InMemoryQueryStore : IQueryStore
{
    private readonly List<DiaryEntryDto> _entries = new();

    public List<DiaryEntryDto> GetAllEntries() => _entries.ToList();

    public DiaryEntryDto GetById(Guid id) =>
        _entries.FirstOrDefault(e => e.Id == id);

    public void Add(DiaryEntryDto dto) => _entries.Add(dto);
}

命令端实现

写操作通过命令消息触发：

public abstract class Command
{
    public Guid AggregateId { get; }
    public int ExpectedVersion { get; }

    protected Command(Guid aggregateId, int expectedVersion)
    {
        AggregateId = aggregateId;
        ExpectedVersion = expectedVersion;
    }
}

public class CreateDiaryEntryCommand : Command
{
    public string Title { get; }
    public string Content { get; }
    public DateTime From { get; }
    public DateTime To { get; }

    public CreateDiaryEntryCommand(Guid id, string title, string content,
        DateTime from, DateTime to, int version)
        : base(id, version)
    {
        Title = title;
        Content = content;
        From = from;
        To = to;
    }
}

命令由命令总线分发至对应处理器：

public interface ICommandBus
{
    void Dispatch<T>(T command) where T : Command;
}

public class SimpleCommandBus : ICommandBus
{
    private readonly IServiceProvider _provider;

    public SimpleCommandBus(IServiceProvider provider) =>
        _provider = provider;

    public void Dispatch<T>(T command) where T : Command
    {
        var handler = _provider.GetService<ICommandHandler<T>>();
        handler?.Handle(command);
    }
}

命令处理器负责构建领域对象并提交变更：

public class CreateDiaryEntryHandler : ICommandHandler<CreateDiaryEntryCommand>
{
    private readonly IRepository<DiaryAggregate> _repo;

    public CreateDiaryEntryHandler(IRepository<DiaryAggregate> repo) =>
        _repo = repo;

    public void Handle(CreateDiaryEntryCommand command)
    {
        var aggregate = new DiaryAggregate(
            command.AggregateId,
            command.Title,
            command.Content,
            command.From,
            command.To);

        _repo.Save(aggregate, command.ExpectedVersion);
    }
}

领域聚合根通过应用事件来改变状态：

public class DiaryAggregate : AggregateRoot
{
    public string Title { get; private set; }
    public string Content { get; private set; }
    public DateTime From { get; private set; }
    public DateTime To { get; private set; }

    public DiaryAggregate(Guid id, string title, string content,
        DateTime from, DateTime to)
    {
        ApplyChange(new DiaryEntryCreatedEvent(id, title, content, from, to));
    }

    public void Apply(DiaryEntryCreatedEvent e)
    {
        Id = e.AggregateId;
        Title = e.Title;
        Content = e.Content;
        From = e.From;
        To = e.To;
        Version = e.Version;
    }
}

最后，事件处理器监听领域事件并更新查询模型：

public class DiaryEntryProjection : IEventHandler<DiaryEntryCreatedEvent>
{
    private readonly IQueryStore _store;

    public DiaryEntryProjection(IQueryStore store) => _store = store;

    public void Handle(DiaryEntryCreatedEvent e)
    {
        var dto = new DiaryEntryDto
        {
            Id = e.AggregateId,
            Title = e.Title,
            Content = e.Content,
            From = e.From,
            To = e.To,
            Version = e.Version
        };

        _store.Add(dto);
    }
}

总结

CQRS通过分离读写关注点，使系统能够在架构层面针对不同需求进行优化。它特别适用于那些对一致性、可追溯性和高性能有较高要求的应用场景。虽然其实现比传统模式更为复杂，尤其是涉及事件驱动和最终一致性时，但对于合适的项目而言，其所带来的灵活性和可扩展性收益是显著的。

需要注意的是，CQRS是一种架构决策，应在充分评估系统复杂性和团队能力后谨慎采用。它可以作为整体架构的一部分，在关键模块中实施，而不必强求全局一致。