CQRS+整洁架构下抽取客户端公共命令基类是否符合设计规范？

核心结论先行 #

很多人对CQRS存在刻板误解，觉得命令必须完全独立、一行重复代码都不能有，其实完全不是。设计ClientBaseCommand作为新增、更新命令的公共父类本身不是违反CQRS的设计，只要边界把控得当，就是兼顾代码复用与架构原则的合理实践；但如果设计时模糊了CQRS对命令独立性的核心要求，就很容易踩坑。

先校准CQRS的核心原则边界 #

CQRS的核心本质是读写模型分离、独立写操作解耦，从来没有禁止命令层的代码复用。判断你的设计是否合规，核心只看两个标尺：

• 每个命令是否依然作为独立的业务意图存在，没有因为复用逻辑和其他命令形成隐性耦合
• 命令的处理管道、处理器是否保持独立，没有因为基类的存在被强制合并

这种设计完全合理的场景 #

当满足以下条件时，抽ClientBaseCommand的收益远大于成本：

• 两类命令的共有字段语义完全一致、校验规则无差异：比如Name、Address、Age三个字段，在Add和Update两个流程里的必填规则、格式校验、权限要求完全相同，没有哪个命令存在特殊的演化逻辑
• 基类仅作为纯数据载体，不掺杂任何业务逻辑：ClientBaseCommand里只定义上述共有属性，不内置校验方法、不依赖任何领域服务、不绑定特定的处理流程；两个子类依然各自独立注册到DI容器、拥有独立的Handler、独立的验证管道
• 后续存在同领域命令的扩展预期：如果未来还会出现ChangeClientContactCommand这类和客户信息修改相关的命令，抽公共基类能避免后续大量重复的字段定义

这种设计踩的红线（即和CQRS原则冲突的情况） #

如果出现以下任意一种情况，这种继承设计就已经偏离了CQRS的核心诉求：

• 为了复用强行凑字段：比如新增命令的Age是必填项，但更新命令的Age是可选字段，为了套基类强行把两个字段的逻辑抹平，最后用大量分支判断兼容差异，反而增加了维护成本
• 基类被塞入通用业务逻辑：比如在ClientBaseCommand里写公共校验方法、公共的权限判断逻辑，把两个独立命令的业务逻辑深度绑定，后续修改一个命令的校验规则时，很容易意外影响另一个命令的行为
• 借基类做命令合并：为了复用代码，写一个泛型处理器同时处理Add和Update两类命令，把两个独立的写操作流程捏合到同一个类里，彻底破坏了CQRS对独立写操作解耦的要求

实操层面的注意点 #

• 不要为了抽字段而抽字段：如果仅有的两个命令、重复的字段加起来不超过10行定义，直接重复写代码的清晰度，远高于引入一层继承的维护成本
• 继承链尽量保持扁平：不要搞多层基类嵌套，避免后续子类演化时出现适配困难
• 不需要强行让所有同领域命令套继承关系：如果某个命令的字段和基类不匹配，独立定义即可，不要为了保持继承体系的完整性硬塞不兼容的属性

内容的提问来源于stack exchange，提问作者Michał Mazur