我正在开发一个关键的旧系统，该系统的数据模型有更改的风险。该系统的工作量由很少的写入和大量的读取组成。
现在，我需要向一些客户端公开一些新的API。要实现这些API，我需要创建新记录或合并旧系统中的多个记录。
考虑到与更改遗留系统相关的风险以及新API中所需数据的复杂性，对我来说，一种解决方案是使用Reporting Database。
另一个可能的解决方案可能是使用类似CQRS的体系结构，以便旧系统继续使用其自己的数据模型（命令部分）存储数据，并使用消息代理将任何更改（事件）传达给另一个系统。 ，以适合客户端查询的方式（查询部分）存储数据。因为此系统总体上是整体的，所以我的事件只能包含已更改实体的标识符，而“查询”部分可以通过直接查询遗留系统的共享数据库来检索完整记录。
我知道与CQRS体系结构相关的复杂性，特别是在分布式系统中。从表面上看，它似乎解决了许多困难，包括修改遗留系统。但是我仍然不确定使用CQRS解决我所描述的问题是否是一个好主意，因为有人认为CQRS仅应在Greenfield项目中使用。
任何建议将不胜感激。
CQRS绝对不仅仅用于绿地。将大型遗留系统转换为CQRS可以成功完成，只需要一些技巧和时间。
关键是在尝试构建报告端之前，将事件管理注入到旧系统中。理想情况下，您在旧系统中使用存储库方法，可以在其中向事件中心添加写入。这些事件写入将是一劳永逸的异步操作，因此它们将为旧系统赖以生存的服务器增加一点负载，但不会影响单个写入的响应率。如果您没有适当的存储库模式，现在可以重构。如果您没有存储库并且不想重构其中的存储库，那么一种不愉快的可能性就是向数据库添加触发器以写出事件。
在注入事件创建逻辑时，您还可以设计报告方。在大多数事件逻辑都未使用之前，我不会开始构建报告方面，因为您将反复从计划中的旧系统中发现所需的新事件。当您意识到需要这些新事件时，报告方的计划将会更改，并且如果已经部分构建了该计划，则最终可能会丢弃您刚刚编写的代码。
事件到位后，只需敲出代码来支持读取端，这很麻烦但很琐碎。
请确保给自己足够的时间来执行此操作。无论您计划多少，此过程都会经历很多尝试和错误，因此肯定会花费您比您想象的更长的时间。如果截止日期很紧，那么复制到报表数据库将使工作更快，更便宜，但是灵活性会降低，并且需要更多维护。
令人惊讶的是，一旦事件发生，它们是多么有用。事件侦听器开始在您可能不会想到的各种不同的系统中弹出，因此，如果您可以让管理层在Eventing方法的较高成本和更长的时间表上获得回报，那么它将得到回报。