Pattern to combine orders from different systems

Question

We have a legacy order system and a new order system that are both currently active. The legacy order system takes 'offline' orders still, the new order system handles 'online' orders but uses the legacy order system for operations, so the legacy system has both offline and online orders. Eventually, the new system will handle all orders, but won't have historical orders in it.

I need a solution that can source order information from both systems and display in a single 'my orders' view for customers. There are a number of cases/rules where the source of the data depends on how the order was created, e.g. the delivery address will come from the legacy system if it was an offline order, but the new system if it was an online order, the billing entity will always come from the legacy system.

As we move functionality these rules will change, i.e. for certain types of offline orders, the delivery address needs to come from the new system regardless of origin.

In some cases, the data may not be in the legacy system, so will be blank, but populated in the new system, so we need defaults and/or fallback ("if not in legacy system, find in new system") behaviour for some data, e.g. products.

Is there a design pattern for this type of aggregation of two sources of data that would minimise future development required as we shift the 'source of truth'?

Answer 1

Depends on the specific case you are trying to resolve, but I guess you could use something like Kafka as an anti corruption layer. That way you have an intermediary of sorts to handle the communication restrictions between the different systems. But any tool that handles what you are describing, even as simple as a repository pattern with extra steps for security constraints will have a learning curve and overhead. It will depend on your specific stack what the best solution might be.