OpenCQRS 抛弃传统聚合根，以“无聚合”理念重构 CQRS，结合现代 Java 与 Spring Boot，打造轻量、灵活、云原生友好的事件驱动开发框架。
CQRS 这个听起来高大上的架构模式，其实可以变得更轻、更简单、更贴近真实业务！
最近，一个叫 OpenCQRS 的新框架横空出世，直接挑战了 CQRS 领域几十年来的“金科玉律”——聚合根（DDD Aggregate）。今天我们就来深度拆解这篇来自 EventSourcingDB 官方博客的重磅访谈，带你看看德国技术团队 Digital Frontiers 是如何“重新思考 CQRS”的！
先说说背景。这篇访谈的主角 Frank Scheffler，是德国知名 IT 咨询公司 Digital Frontiers 的联合创始人兼技术负责人。这家公司专注于企业数字化和云原生解决方案，在事件驱动架构和事件溯源（Event Sourcing）领域深耕多年。而 OpenCQRS 正是他们基于自家数据库 EventSourcingDB 打造的全新 CQRS 框架，如今已正式发布 1.0 版本，不少客户甚至早在测试版阶段就已投入生产环境使用，稳定性可见一斑。
那 OpenCQRS 到底有什么不一样？核心就一句话：它彻底抛弃了“聚合根”这个概念，提出了“无聚合”（No Aggregate）的设计哲学。
注意，不是“干掉聚合”，而是“根本不需要它”。
Frank 在访谈中直言，传统 CQRS 框架里那个叫 Aggregate 的东西，其实是个“历史遗留问题”——名字听起来很专业，但实际解决的问题并不清晰。在事件溯源的世界里，真正重要的是事件本身。你要判断一个命令能不能执行，只需要把相关的事件“聚合”起来做决策就行，根本不需要一个叫“聚合根”的类来承载状态。
更颠覆的是，OpenCQRS 认为：同一个业务实体，面对不同命令时，完全可以使用完全不同的写模型。比如处理“借书”命令时，你只需要知道这本书是否已被借出；而处理“下架”命令时，你可能更关心这本书有没有逾期未还。这两个场景Context需要的事件数据完全不同，何必强行塞进同一个 Aggregate 类里？用 Java 21 的 record（不可变记录类）就能轻松搞定，代码更干净，逻辑更聚焦。
（其实聚合是限定上下文里的聚合，这两个场景上下文不同，就是不同聚合）
说到这里，你可能会联想到 Sara Pellegrini 那场著名的演讲《Kill Aggregate!》。但 Frank 特意强调，他们的理念不是“杀死”，而是“无需”。
对新手来说，这反而降低了门槛——你不用先理解 DDD 里那些复杂的术语，直接从业务约束出发写命令处理器就行。而对老手来说，则需要一点“反学习”：放下对 Aggregate 的执念，拥抱更灵活的事件驱动思维。
技术栈方面，OpenCQRS 毫不掩饰对 Spring Boot 的偏爱。它原生支持 Spring Boot 3.x，最低要求 Java 21，充分利用了现代 Java 的特性，比如 sealed class 和 record。通过简单的注解，你就能定义命令处理器和事件处理器，框架自动帮你完成注册和调度。但别担心被绑定——OpenCQRS 的核心是纯 Java 实现，Spring 只是其中一层适配器。未来完全可能支持 Ktor、Quarkus 等其他框架，社区贡献的大门始终敞开。
说到测试，Frank 作为 TDD（测试驱动开发）的铁杆粉丝，把测试体验做到了极致。传统分层架构里，测试往往陷入“Mock 地狱”——为了测一个方法，要模拟十几层依赖，代码又臭又长。而 CQRS 天然适合黑盒测试：输入是命令，输出是事件，就像 Unix 的 stdin 和 stdout 一样清晰。OpenCQRS 提供了流畅的 Given-When-Then 测试 API，你甚至可以在写实现前就先把测试用例写好，真正做到“测试先行”。
轻量级是 OpenCQRS 的另一大标签。它不做过度封装，不搞“万能抽象”。比如，默认情况下事件处理器是非事务性的，但如果你需要事务，只需加个 @Transactional 注解就行。它也不重复造轮子——分布式选主这种问题，直接推荐你用 Spring Integration 解决。整个框架坚持“最少侵入、最大灵活”的原则，让你专注业务，而不是框架本身。
在云原生和高并发场景下，OpenCQRS 同样表现出色。它完全摒弃了中心化的协调器（比如 Saga Orchestrator），推崇“编舞式”（Choreography）架构——服务之间通过事件异步协作，天然具备水平扩展能力。命令处理靠 EventSourcingDB 的乐观锁机制保证一致性；事件消费则通过分布式锁或选主策略避免重复处理。整个系统既可扩展又可靠，还不依赖任何中心节点。
（这个EventSourcingDB是聚合了，他说没有Java代码聚合，然后就用数据库作为共享聚合，其实不是聚合问题，是上下文共享问题：别再被“共享”骗了！上下文混用才是系统崩溃的元凶）
开发者反馈也印证了这一点：很多人说用 OpenCQRS 写代码“特别顺”，上手快、没负担。Frank 谦虚地表示现在下结论还太早，但他坚信，只要坚持初心，这个框架就能长期保持简洁与强大。
最后聊聊未来：团队正在开发 DCB（Dynamic Command Boundaries）功能，允许每个命令动态查询所需事件，进一步提升灵活性。同时也在规划 GDPR 合规支持，满足企业级需求。而这一切，都建立在与 EventSourcingDB 的深度集成之上——Frank 明确反对“抽象到可以随意替换事件存储”的做法，认为那是 J2EE 时代的错误复刻。事件存储远比 SQL 数据库复杂，与其搞虚假的可移植性，不如深度优化与特定存储的协同。
给新手的建议也很实在：先搞懂 CQRS 基础，别一上来就挑战复杂业务。官方提供了图书管理的入门示例和详细指南，配合强大的测试工具，能帮你快速上手。记住，CQRS 不是银弹，但用对了地方，它能让你的系统更清晰、更健壮、更易演进。
总结一下，OpenCQRS 不是一次小修小补，而是一场对 CQRS 范式的重新思考。它用“无聚合”解放了开发者，用现代 Java 提升了体验，用云原生设计保障了扩展性，用极致测试支持了工程实践。如果你正在考虑事件驱动架构，或者对现有 CQRS 框架感到臃肿，那 OpenCQRS 绝对值得你关注。
作者 Frank Scheffler 是德国 Digital Frontiers 公司的联合创始人，长期专注于云原生、事件驱动架构和企业级系统设计，是 EventSourcingDB 与 OpenCQRS 的核心推动者。
opencqrs：https://docs.opencqrs.com/