使用 CQRS 改进传统的单体系统

Question

我正在开发一个关键的遗留系统，它的数据模型存在更改的风险。该系统的工作负载由相当少的写入和大量读取组成。

现在，我需要向一些客户端公开一些新的 API。要实现这些 API，我需要创建新记录或合并旧系统中的多个记录。

考虑到与更改旧系统相关的风险以及新 API 所需数据的复杂性，我的一个解决方案是使用Reporting Database。

另一种可能的解决方案是使用类似 CQRS 的架构，以便旧系统继续使用自己的数据模型（命令部分）存储数据，并使用消息代理将任何更改（事件）传达给另一个系统，它以适合客户端查询的方式存储数据（查询部分）。因为这个系统整体是单体的，所以我的事件只能包含改变实体的标识符，而查询部分可以通过直接查询遗留系统的共享数据库来检索完整的记录。

我知道与 CQRS 架构相关的复杂性，尤其是在分布式系统中。在纸面上，它似乎解决了很多困难，包括修改遗留系统。但是我仍然不确定使用 CQRS 来解决我描述的问题是否是一个好主意，因为有些人认为 CQRS 应该只用于新建项目。

任何建议将不胜感激。

Answer 1

CQRS 绝对不仅仅适用于新领域。将大型遗留系统转换为 CQRS 可以成功，只是需要一点技巧和时间。

关键是在尝试构建报告端之前将事件管理注入遗留系统。理想情况下，您在遗留系统中有一个存储库方法，您可以在其中将写入添加到事件中心。这些事件写入将是即发即弃的异步，因此它们会给遗留系统所在的服务器增加一点负载，但不应影响单个写入的响应率。如果您没有适当的存储库模式，那么现在可能是重构的时候了。如果您没有存储库并且不想重构其中一个，那么一种令人不快的可能性是向数据库添加触发器以写出事件。

在注入事件创建逻辑的同时，您还可以设计报告端。在大多数事件逻辑出现之前，我不会开始构建报告端，因为您会反复从旧系统中发现您没有计划的新事件。当您意识到您需要这些新事件时，您的报告方面的计划将会改变，如果您已经部分构建了它，您最终可能会丢弃刚刚编写的代码。

一旦事件到位，只需敲出代码以支持读取端，这很费力但微不足道。

请务必给自己足够的时间来执行此操作。无论您计划多少，在此过程中都会有很多试验和错误，因此它肯定会花费您比您想象的更长的时间。如果截止日期很紧，复制到报告数据库可以更快、更便宜地完成工作，但它的灵活性会降低，并且需要更多的维护。

令人惊讶的是，一旦事件到位，它们的用处之大。事件侦听器开始出现在您从未想过的各种不同系统中，因此，如果您可以让管理层接受事件处理方法的更高成本和更长的时间线，那么它将获得回报。