I'm quite new to DDD and Event Driven architectures. And after searching this issue I did not manage to get a clear answer by myself, so I'll appreciate if someone can clarify this.
Suppose I currently have an app with 2 bounded contexts. ContextA emits some InterestingEvent that propagates through an integration event to ContextB. This allows ContextB to have its own representation about some eventual state each time this event is emitted and picked up.
So far so good.
But this happy path assumes that ContextA and ContextB have always existed or ContextB has always been subscribed to the InterestingEvent.
Suppose now ContextA existed a while before ContextB... or they both existed, but ContextB was not subscribed initially to InterestingEvent. As a result from this, a number of InterestingEvents have already happened when ContextB goes online or subscribes to the event.
What are the strategies for ContextB to deal with this "first sync" or "past events" situation?
Some crazy thoughts:
Is ContextA suppose to replay all events ContextB requires to be up to date? That could be problematic in the sense that some of this events may have side effects in other contexts as well.
Do ContextB may ask for an update batch from ContextA at bootstrap? Kind of a fat-full-state Godzilla event that carries all the state ContextB needs to be on sync?
Thanks in advance.
What are the strategies for ContextB to deal with this "first sync" or "past events" situation?
The most common strategy I've seen in expert discussion is that new subscribers pull event histories, rather than expecting them to be pushed.
In other words, the basic idea is that the thing-being-subscribed-to is an append-only ordered sequence of events; as the subscriber, I track some token that identifies the most recent event that I have seen, and when I'm ready for new events I ask the provider "Have there been any events since [token]?"
For new subscribers, the basic idea is the same, except that we use some special token/message that means "I haven't seen any events yet".
Of course, event histories are not the only way you can copy information across a boundary; in some domains, it will make sense to ask for a snapshot of information aka import aka bulk transfer. That representation of information can, of course, include in it some metadata that the representation is valid as at [token], and the subscriber, after processing the import, and then ask if there have been any updates since token.
Recommended viewing: Polyglot Data (Greg Young, 2014)