Dag Philippe,
Wat betreft het eerste probleem: er zijn natuurlijk altijd meerdere oplossingen en keuzes over waar de controle juist gebeurd, maar in dit geval lijkt een goede optie mij om app C een event te laten sturen nadat het de info van app A heeft verwerkt. App B kan dan hierop wachten alvorens de vraag te stellen aan C.
Het complexere geval met app D: Ook hier kan C eventueel wachten op een event notificatie van D (én uiteraard ook B). Ik zou echter wel vermijden dat meerdere applicaties gebruik maken van dezelfde achterliggende database. Voor mij is dat een anti-pattern 🙂 .

Mogelijk is er vanuit EDA een antwoord op problemen die we daar al kennen:
Applicatie A produceert een event.
Applicatie B verwerkt dit event. Applicatie B wil nu informatie van Applicatie C en past in zijn vraag om die informatie al de context aan aan de verwerking van het event van Applicatie A.
Is er een garantie dat Applicatie C eerst het event van Applicatie A verwerkt vooraleer de vraag van Applicatie B te verwerken?

Ik veronderstel dat in het ideale geval de vraag van Applicatie B ook een event is en er een orde is in de events zodat we zeker zijn dat Applicatie C de events in de correcte orde verwerkt.
Complexer geval als het Applicatie D is die het event van Applicatie A moet verwerken (door bv iets aan te passen in een achterliggende database) en Applicatie C die het event van Applicatie B verwerkt (door een query uit te voeren op die achterliggende database).

Hoe gaat EDA met dergelijke gevallen om?

je beschrijf dit als 4 stappen, maar ik denk dat dit niet noodzakelijk “niveau’s” van EDA zijn maar misschien eerder patterns die in bepaalde context kunnen toegepast worden.

Wouter