传统系统的CQRS [英] CQRS with Legacy Systems

问题描述

我希望将具有清晰域模型的相对较新的基于Web的应用程序转换为更多的CQRS样式系统。我的新应用程序实质上是对较旧的现有系统的增强替代。

我组织中的现有系统共享一组通用数据库，这些数据库通过无数的更新。应用程序（通过混沌方法开发）存在于整个公司的孤岛中。 （按现状，我相信公司中没有一个人能全部识别出他们。）

因此，我的问题是关于我的应用程序的读取模型。由于各种状态变化，一般用户数据等都由我控制范围之外的其他应用程序更新，因此以这种方式处理读取模型的最佳方法是什么，即我可以处理外部更新，但仍然使事情相对简单？ / p>

到目前为止，我已经考虑以下内容：

1. 在数据库中创建视图对于读取模型，读取所有旧表和旧表


2. 向现有表添加触发器以更新新的读取模型表


3. 向数据库（CLR存储的proc / etc [sql服务器]）以更新读取模型的外部数据存储


4. 放弃希望

如何处理此问题的普遍共识是什么？认为我可以在不从头开始完全重写所有内容的情况下将命令带给旧系统是愚蠢的吗？

解决方案

我曾经遇到过类似的情况，以下是我的操作步骤：

要改进旧版系统并获得更清晰的代码库，关键是接管写责任。但是不要太雄心勃勃，因为这可能会导致界面/合同更改，从而使最终部署具有风险。

1. 如果所有写操作都通过除直接sql更新以外的任何操作触发，请尽可能使它们向后兼容。将它们作为新开发的命令处理程序的适配器/客户端。




2. 某些写入操作是直接sql更新，但不受您的控制
   
   询问负责团队是否可以更改为您的新界面/合同？
   
   如果没有，请参见步骤3。




3. 询问如果他们可以忍受最终的一致性并愿意用数据库过程替换sql更新？
   
   如果是，请将所有sql更新放入过程中并安排部署，请参见步骤4。
   
   如果不是，也许您应该将它们包括在重构中。




4. 修改过程，用插入事件替换sql更新。并开发后端工作来滚动事件并发布它们。让您的新应用程序订阅这些事件以向命令处理程序发送命令。




5. 从命令处理程序中发出事件，并使用它们来更新其他应用程序使用的表




6. 移动到旧版系统的下一部分。

I'm looking to convert a relatively new web-based application with a clear domain model over to more of a CQRS style system. My new application is essentially an enhanced replacement of an older existing system.

The existing systems in my organization share a set of common databases, which are updated by an untold number of applications (developed via the Chaos Method) that exist in silos throughout the company. (As it stands, I believe that no single person in the company can identify them all.)

My question is therefore about the read model(s) for my application. Since various status changes, general user data, etc. are updated by other applications outside my control, what's the best way to handle building the read models in such a way that I can deal with outside updates, but still keep things relatively simple?

I've considered the following so far:

1. Create Views in the database for read models, that read all tables, legacy and new
2. Add triggers to existing tables to update new read model tables
3. Add some code to the database (CLR Stored proc/etc [sql server]) to update an outside datastore for read models
4. Abandon hope

What is the general consensus on how to approach this? Is it folly to think I can bring order to a legacy system without fully rewriting everything from scratch?

解决方案

I once was in a similar situation, the following steps was how i did it:

To improve the legacy system and achieve cleaner code base, the key is to take over the write responsibility. But don't be too ambitious as this may introduce interface/contract changing which makes the final deployment risky.

1. If all the write are fired through anything except direct sql updates, keep them backward compatible as possible as you can. Take them as adapters/clients of your newly developed command handlers.

2. Some of the write are direct sql updates but out of your control
   Ask the team in charge if they can change to your new interface/contract?
   If no, see step 3.

3. Ask if they can tolerate eventual consistency and are willing to replace the sql updates with database procedures?
   If yes, put all the sql updates in the procedures and schedule a deployment and see step 4.
   If no, maybe you should include them in your refactoring.

4. Modify the procedure, replace the sql updates with inserting events. And develop a backend job to roll the events and publish them. Make your new application subscribing these events to fire commands to your command handlers.

5. Emitting events from your command handlers and use them to update the tables that other applications used to consume.

6. Move to the next part of the legacy system.

这篇关于传统系统的CQRS的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！