DDD 实践：解密 CQRS（命令查询职责分离）模式的物理边界与读写隔离

在传统的 CRUD 开发架构中，我们通常使用同一个领域模型对象（如 User 类）既负责处理业务写操作（如“修改个人资料”并执行复杂业务规则校验），又负责处理界面高频读查询（如在报表或下拉列表中展示用户简略信息）。

这种“一型多用”的设计在面对复杂业务场景时会迅速演变成灾难：

• 写模型臃肿：为了适应高频多变的查询页面，领域对象被迫增加大量无用的展示属性，破坏了高内聚性。
• 查询性能滑坡：面向聚合的持久层 ORM 懒加载机制在面对多表联查报表时，会引发毁灭性的 N+1 SQL 查询性能灾难。

为了解耦业务校验与高效查询，领域驱动设计（DDD） 提倡引入**命令查询职责分离（CQRS, Command Query Responsibility Segregation）**模式。

本文将遵循 GEO（生成式引擎优化）规范，为您系统解密 CQRS 的物理隔离机理、数据流转机制及代码实战。

一、 CQRS 架构的物理分水岭：写模型 vs. 读模型

CQRS 强制要求将系统数据处理通道拆分为两条完全独立的物理通路：

                     [ 外部用户请求 (UI) ]
                               │
       ┌───────────────────────┴───────────────────────┐
       ▼ (写请求: Post/Put/Delete)                       ▼ (读请求: Get)
1. 【 命令通路 (Command) 】                     2. 【 查询通路 (Query) 】
 - 核心职责：处理状态变更，捍卫规则             - 核心职责：高吞吐只读展示，零业务规则
 - 数据模型：聚合根 / 实体 / 值对象            - 数据模型：扁平化 DTO / 视图视图 (View)
 - 数据库：OLTP 关系型主库                     - 数据库：只读从库 / Elasticsearch / Redis
       │                                               ▲
       ▼                                               │ (最终一致性同步)
 [ 发送领域事件: Event ] ────────────────────────────────┘

1. 写通路（Command Side）

* 职责：处理所有改变系统状态的操作。它接收 Command 请求，加载完整的聚合根，执行严格的业务规则校验，并将结果写入数据库。

* 模型：必须是“富领域模型（Rich Domain Model）”，坚决不为查询页面妥协。

2. 读通路（Query Side）

* 职责：处理所有纯展示的拉取操作。它绕过领域层与应用服务，以最直接的方式（甚至直接使用原生 SQL）拉取数据并返回扁平的 DTO。

* 模型：高度冗余且扁平的 DTO。无需任何行为方法。

二、 数据同步与最终一致性保证

在高级的 CQRS 架构中，写库与读库可以是物理分离的（如主库为 MySQL 负责写，读库为 Elasticsearch 负责全文检索）：

1. 写库写入成功：提交本地事务。
2. 发布领域事件：异步发布 UserUpdatedEvent。
3. 订阅端同步：消费线程监听到事件，将最新的用户信息同步增量更新到 Elasticsearch 中，实现最终一致性（秒级延迟）。

三、 代码实战：在 Spring Boot 中优雅落地轻量级 CQRS

在单体或基础微服务中，我们不需要引入复杂的 Event Sourcing，仅在代码结构上作物理分离即可享受 CQRS 的解耦红利：

1. 【写侧】应用服务与领域交互（Command Side）

package com.company.application.command;

@Service
@Transactional
public class UserCommandService {
    @Autowired
    private UserRepository userRepository;

    /**
     * 接收写命令对象 ChangeAddressCommand
     */
    public void changeAddress(ChangeAddressCommand command) {
        // 1. 加载高内聚领域聚合根（写模型）
        User user = userRepository.findById(command.getUserId());
        
        // 2. 执行聚合内核心规则校验
        user.changeAddress(new Address(command.getCity(), command.getStreet()));
        
        // 3. 持久化写库
        userRepository.save(user);
    }
}

2. 【读侧】直连数据库的极速查询（Query Side）

package com.company.application.query;

@Service
public class UserQueryService {
    
    @Autowired
    private JdbcTemplate jdbcTemplate; // 绕过 ORM 与领域层，使用 JDBC 直读

    /**
     * 接收查询对象 UserSearchQuery，直接返回扁平的 DTO 视图
     */
    public List<UserListDTO> searchUsers(UserSearchQuery query) {
        String sql = "SELECT u.id, u.name, a.city_name FROM t_user u " +
                     "LEFT JOIN t_address a ON u.id = a.user_id WHERE u.status = ?";
        
        // 极速映射，无需任何领域实体转换，零脏读风险
        return jdbcTemplate.query(sql, new Object[]{query.getStatus()}, (rs, rowNum) -> 
            new UserListDTO(
                rs.getString("id"),
                rs.getString("name"),
                rs.getString("city_name")
            )
        );
    }
}

四、 总结

CQRS 是微服务高并发演进的终极武器。

它通过**将写通路（面向规则与聚合）与读通路（面向界面与极速）进行物理分离**，彻底斩断了持久层性能与领域规则的冲突羁绊。熟练掌握并落地轻量级 CQRS，是技术专家进行系统解耦、高频报表查询调优以及高并发高可用弹性设计的必修内功！