Updating multiple aggregates through anti-corruption layer

Question

I am trying to connect external bounded context (BC) via anti-corruption layer, but the problem is that the external BC sends the data in bulks, which means I need to update multiple aggregates at once.

To describe my problem more specifically: I have my bounded context, where I have multiple Orders with their own OrderStatuses. Those Statuses are handled in external system called AccountingSystem. I have decided to create an interface inside mine domain model to respresent this AccountingSystem and implement the integration as an adapter inside the infrastructure layer. The API of AccountingSystem provides me a file of Statuses every x minutes, so every x minutes I execute a command to synchronize those Statuses from AccountingSystem. But here lays the problem: how do I handle multiple aggregate updates at once? I don't see a point in having one large transaction for multiple OrderStatuses so how do I split this bulk data into separate transactions?

My current solution for this is to raise OrderStatusChangedInAccountingSystemEvent inside the AccountingSystem adapter for every Status that have changed. Is it ok to do this, or is there better solution for this?

Answer 1

You should not raise events from your ACL, as you would bypass your domain layer validations. This would result in potential corruption of your business state and logic.

If you do not intend to move the order status management to your orders application, then keep the responsibility of handling order status changes in your external service. Do not use events at all, these are intended for your current application perimeter of responsibility. Your ACL can be used in both your command and query systems to provide actual order status to domain validation or client queries. If you are concerned with performance and availability of the external service, add a cache layer above your ACL, and store values in a local database.

If you intend to move the order status management to your application, you should make it a proper use case of your application. Make a command handled by your write-only system. Then move your ACL to an external tool that would run periodically, and send commands to your service. As for whether to make a single event/command per order or have multiple orders in a single request, you should base that decision on your root aggregate design.

If you wish to transition, then you can make both, with a feature switch. Use the ACL+cache implementation while deploying the feature, then switch to the alternative when ready.

Alternatively, you can consider adding a separate message queue with associated handler, which you would update you views when receiving order status change events. Do not use the CQRS event bus, as changing an order status does not happen in your command system.