I am remodeling .net core application and facing following problem. In said application I identified potential aggregate roots, lets say three of them Exam, Patient, ServiceProvider should be created during single command processing (I am using Mediatr as command handler). Mentioned AR are related to each other: Exam -> exam.PatientId, Exam -> exam.ServiceProviderId
So in order to create Exam I need to create Patient and ServiceProvider earlier. I got few ideas to handle this, but none of them seems to feel right.
I would realy like to hear any opinions on this, since it seems to be pretty common situation.
Aggregates (apart of their domain knowledge) are designed for transactional consistency, meaning that whatever is inside an aggregate is designed to have immediate consistency when saved otherwise there wouldn't be such need. This may be true for 90% of the time (e.g.: after creation maybe you will always need to save the other aggregates separately because they no longer interact directly with each other) so you decide to design all 3 Aggregates separately. In the other 10% you can use a transaction to save 3 Aggregates at once. This is totally fine. The only downside is that when this use case is executed you have a bigger "contingency" but that's it. It's up to you to evaluate if this is critical or not.