Communication between contexts - Implement RemoveCustomer method that checks if customer has any orders. about sample-dotnet-core-cqrs-api HOT 2 CLOSED

Hi @jmalczak,

There are many ways to implement this kind of behavior, all of them have pros and cons:

1. Treat Customer and his Orders as a whole - the Aggregate Pattern. So you load all orders together with the Customer and protect this invariant ("you cannot remove Customer with Orders"). The main advantage is that you will have strong consistency (because Aggregate is a consistency boundary). The main disadvantage is performance - you need load and save always the whole Aggregate.

2. Load data about Orders in Application Service and check this logic. Checking this logic can be done in Application Service or in the Aggregate Root method. The main advantage is that you don't need to always load all orders together with the Customer entity - only during removing use case. The drawback is that between loading data and performing the action (removal) there is a small amount of time and in that time the state of the system could change (for example first order was placed). So there is a "small" chance that this rule will be broken.

3. Use database constraints. Yes, your business logic should not be in the database, but sometimes it is unavoidable or it is the easiest solution. So you can use FK constraint (if you performing hard delete) or even the trigger (yes, evil) if you performing soft delete (using some kind of status or flag). Advantage - strong consistency, disadvantage - business logic in the database, harder to test, maintain, less readable etc.

4. Similar approach to what you described. You can have a flag on the Customer called "CanBeDeleted" with default value "true" and after adding new Order it can be set to false. Advantage - performance, because you have done some aggregation/precalculation. Disadvantage - you need to keep this flag up to date.

Back to your question about communication between context. If you need strong consistency you need to have Customer and his Orders in the same context. If you don't need strong consistency you can apply approach nr. 2 (ask other context) or communicate by events and store information in Customer context (approach nr 4.)

from sample-dotnet-core-cqrs-api.

Great answer, thanks for the explanation!

from sample-dotnet-core-cqrs-api.