CQRS（Command Query Responsibility Segregation）是命令与查询职责分离的模式。

核心思想：把数据的写操作（Command）和读操作（Query）分开处理。

传统方式 vs CQRS
传统：同一个 Service/Repository 既读又写
┌────────────────┐
│ BudgetService │
│ ├─ getById() │ ← 读
│ ├─ save() │ ← 写
│ ├─ update() │ ← 写
│ └─ delete() │ ← 写
│ └─ list() │ ← 读
└────────────────────┘

CQRS：读写分离
┌────────────────┐ ┌────────┐
│ Query 侧 │ Command 侧 │
│ ├─ getById() │ │ ├─ save() │
│ ├─ list() │ │ ├─ update() │
│ ├─ search() │ │ ├─ delete() │
│ └─ 绑定查询模型 │ │ └─ 绑定写模型 │
│ (BudgetControlModel)│ │ (BudgetPackageControl)│
└────────────────────┘ └────────────────┘

我们项目中的应用
刚才的重构其实就是 CQRS 思路：

| 层 | 职责 | 模型 | |----|------|

| Repository（查询侧） | 只做数据读取，返回 Entity | BudgetPackageControl |

| Service（命令侧） | 业务编排：校验、ID生成、事务控制 | BudgetControlModel / BudgetControlSaveDTO |

好处：

读侧可以优化查询性能（比如用不同的 SQL、缓存、甚至不同的数据库）
写侧专注业务逻辑和事务一致性
模型解耦：查询返回的 Model 和写入用的 DTO/Entity 可以不一样，各自演化不互相影响

什么时候该用 CQRS？
| 场景 | 建议 | |------|

| 简单 CRUD | 不需要，传统方式够用 |

| 读多写少，读逻辑复杂 | 适合，查询侧可以独立优化 | | 写操作有复杂业务编排 | 适合，命令侧集中管理事务 | | 读写模型差异大 | 适合，避免一个模型既满足读又满足写 |

我们项目当前属于"写操作有复杂业务编排"的场景（copy、batchSave 涉及多表事务），所以用 CQRS 分开是合理的。