我正在寻找将具有清晰域模型的相对较新的基于Web的应用程序转换为更多CQRS样式系统。我的新应用程序本质上是旧的现有系统的增强替代品。
我组织中的现有系统共享一组公共数据库，这些数据库由遍布公司的孤岛中的无数应用程序（通过混沌方法开发）进行更新。 （就目前而言，我相信公司中没有任何一个人可以识别所有人。）
因此，我的问题是关于我的应用程序的读取模型。由于各种状态更改，一般用户数据等由我无法控制的其他应用程序更新，处理构建读取模型的最佳方法是什么，以便我可以处理外部更新，但仍然保持相对简单的事情？
到目前为止我考虑过以下几点：
关于如何处理这个问题的一般共识是什么？认为如果不从头开始完全重写所有内容，我可以为遗留系统带来秩序，这是愚蠢的吗？
我已成功使用选项＃1。根据写入数据库的复杂性，创建视图以使数据士气低落以创建读取模型是可行的选择。意思是，如果它是大多数开发人员可以理解的相对简单的连接，那么我会仔细研究一下它是否适合您。我会小心这些观点过于复杂。
另一件需要考虑的事情是定期轮询以构建和更新类似于传统的报告数据库。虽然与通知相比不是最佳的，但根据您的读取模型的陈旧程度，这也可能是一个选项。
我曾经处于类似的情况，以下步骤是我如何做到的：
要改进遗留系统并实现更清晰的代码库，关键是接管写入责任。但不要过于雄心勃勃，因为这可能会引入接口/合同变更，这使得最终部署风险很大。
如果我们有一个无限强大的服务器，我们就不会打扰视图模型而只是从基本实体表中读取。视图模型旨在通过准备和维护适当的数据集进行显示来提高性能。如果您使用数据库View作为视图模型，那么对于adhoc查询，您实际上没有获得太多的性能提升（如果您忽略了sql解析器可以为视图执行的预先计划）。
我有一个比@ Hippoom的解决方案更少侵入性的解决方案，但比@ Derek的响应更快。如果您可以访问旧系统并且可以进行少量代码更改，则可以添加异步队列写入以在遗留系统存储库中的队列系统（RabbitMQ，Kafka或其他）中生成事件，或者在数据持久存储的任何位置生成事件。使这些写入异步不应该引入任何显着的性能成本，并且如果队列写入失败，它将不会影响遗留系统。这种变化也很容易通过QA。
然后编写一个事件驱动的片段来更新您的阅读模型。在遗留系统更新阶段（可能需要一段时间），或者如果您只能访问写入这些数据库的某些遗留系统，您可以使用一个小型实用程序，每次将新的“UpdateViewModel”事件放入队列中几分钟。然后，当遗留系统保存重要内容时，您将获得及时的事件，但是对于您无法更新的系统也适用。