We have an application A which has its own domain model and database (SQLSERVER). Another application B has its own domain model and database. We want to create another application C which is to create a more generic model to comprise the model from app A and app B. App C doesn't generate any primary data and it all comes from application A, application B, and other external system in the future.
The question is about how to sync data from app A to app C. The plan is to use RabbitMQ to send messages to application C whenever something changes in application A. However, there are a lot of business logic in application A which can makes the data change and the changes need to sync with application C. If we use event driven architecture, there will be many business flow in application A to send the event.
So we want to have another way to do it: capture data changes on database level and then somehow based on the data changes, convert it what we want to do for the model on Application C (insert/update/delete), and query application A to get the tailored model for Application C send them through RabbitMQ in payload.
To capture the changes, we can use Change Tracking \ Data Change Capture \ temporal table or others. To send the data changes from database, we can:
- use scheduled job to poll the changes
- create a CLR and use database trigger to send the data changes to RabbitMQ through CLR
I am more leaned to event-driven architecture, but the database level data sync looks like be able to saving dev and QA time.
Which way should go? Any idea is welcome.
Data Tracking looks good to capture all the changes in the targeted tables. We got the primary key of the changed rows and then we can send the message of data change by using Hangfire.
I am a bit worried on the side effect of Database Trigger. The previous experience with Trigger is the negative performance impact.