命令-查询分离原则（Command-Query Separation）

原文：xuanhu.info/projects/it...

命令-查询分离原则（Command-Query Separation）

核心概念解析

💡 命令-查询分离（CQS） 是Bertrand Meyer在Eiffel语言中提出的设计原则：

"函数应当要么执行操作（命令），要么返回数据（查询），但绝不两者兼施"

关键区别

类型	特征	副作用
命令	修改系统状态（如：保存数据）	✅ 有
查询	获取系统状态（如：读取数据）	❌ 无

典型反模式案例

问题代码实现

javascript 复制代码

// 反例：混合命令与查询的函数
async function refreshAndGetStats(user, newName) {
  await refreshStatsFromDB()   // 命令：触发数据库同步
  addEventToTimeDB()           // 命令：记录时间事件
  await cleanupOldStats()      // 命令：清理旧数据
  
  return await getCachedStats() // 查询：获取统计数据
}

该设计引发的三大问题

隐藏的运维成本

CRON任务调用此函数时，意外触发全量数据刷新，导致数据库负载激增📈
意图模糊性

开发者调用函数时无法预知：
- 是否修改了系统状态❓
- 是否触发昂贵操作💸
违反单一职责

函数同时承担：
- 数据更新（命令）
- 缓存清理（命令）
- 数据获取（查询）

CQS重构方案

分离后的核心函数

javascript 复制代码

// 纯查询：无副作用获取数据
async function getStats() {
  return await getCachedStats() 
}

// 纯命令：仅执行状态变更
async function refreshStats() {
  await refreshStatsFromDB()
  await cleanupOldStats()
}

复合操作的特殊处理

javascript 复制代码

// 界面刷新按钮的事件处理器
async function handleRefreshClick() {
  await refreshStats()         // 执行更新命令
  addEventToTimeDB()          // 记录用户行为
  return await getStats()     // 返回最新数据
}

// CRON任务专用逻辑
async function cronDataProcessor() {
  const stats = await getStats() // 安全获取数据
  // ...后续处理逻辑
}

工程实践要点

分层适用原则

代码层级	CQS适用性	示例
基础工具函数	必须遵守	`getUser()` / `updateConfig()`
业务组合逻辑	灵活处理	按钮事件处理器
系统入口点	豁免	API控制器 / Cron任务

实施收益验证

深度扩展思考

与CQRS模式的关系

虽然CQS是函数级设计原则，但其思想延伸出命令查询职责分离（CQRS） 架构模式：

命令端：Create/Update/Delete操作，返回执行状态
查询端：返回DTO视图，完全无状态

函数式编程的印证

在FP中表现为：

haskell 复制代码

-- 命令式函数（IO操作）
updateDB :: Record -> IO ()

-- 查询式函数（纯函数）
calculateStats :: [Record] -> StatsReport

总结

::: tip 💎 核心价值矩阵

维度	改进前	改进后
可读性	需深入理解实现细节	函数名即契约
可维护性	修改风险波及多处	变更影响局部化
可测性	需要复杂mock	可独立测试各功能单元
系统稳定	存在隐性资源消耗	资源消耗透明可控
:::

🚀 实施路线图

审计现有代码库

扫描混合命令/查询的函数（通过静态分析工具）
渐进式重构

优先修改高频调用或性能敏感模块
建立团队规范

在Code Review中增加CQS检查项

经验法则 ：当函数名包含"And"时（如getAndUpdate），往往是违反CQS的信号⚠️
原文：xuanhu.info/projects/it...