使用CQRS改进遗留单片系统

Question

我正在研究一个关键的遗留系统，它的数据模型很难改变。该系统的工作负载由相当少的写操作和大量的读操作组成。

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

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

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

我知道与CQRS架构相关的复杂性，特别是在分布式系统中。从理论上讲，它似乎解决了许多困难，包括修改遗留系统。但我仍然不确定使用CQRS来解决我所描述的问题是否是一个好主意，考虑到一些人认为CQRS应该只在Greenfield项目中使用。

任何建议都将不胜感激。

Answer 1

CQRS绝对不只是针对绿地的。将大型遗留系统转换到CQRS是可以成功完成的，这只需要一点技巧和时间。

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

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

一旦事件就位，就只需敲出代码来支持读取端，这很费力，但却很琐碎。

一定要给自己足够的时间来做这件事。不管你有多少计划，在这个过程中都会有很多的尝试和错误，所以它肯定会花费你比你想象的更长的时间。如果截止日期很紧，复制到报告数据库会更快、更便宜地完成这项工作，但它的灵活性较低，并且需要更多的维护。

令人惊讶的是，一旦事件就位，它们是多么有用。事件监听器开始在你想不到的各种不同的系统中出现，所以如果你能让管理层接受Eventing方法更高的成本和更长的时间线，它将会得到回报。