My application ecosystem contains a number of bounded contexts and micro services and we are just starting to leverage an event-driven architecture and, hopefully, some event-sourced aggregates as well.
I’ve read some opinions that each context should have its own event store and only publish “integration” events across boundaries and not share its event store.
What is the current thinking in the EventStoreDb world?
Thanks in advance,
Andy
Stream databases like ES by thier fundamental architecture keep data in separate streams.
In comparison, Relational databases are designed to join data with set operations and keys.
So while use separate DB instances make a great deal of sense for relational or even document dbs, it is generally fine in practice to have multiple domains in a single ESDB.
There’s one caveat to watch out for. If you have two contexts that have aggregate types that have the same name with different contextual meanings, the common approach of building the stream name as AggregateType-AggregateId will lead to conflicts, obviously. You may want to explicitly separate streams from different contexts by adding a prefix to stream names, like Payments-PaymentRegistered-123 and Bookings-PaymentRegistered-123. Of course, if you use the category stream for projecting aggregate state to a read model, it stops working. I would not do that anyway. But then, the category streams would serve you a better purpose as $ce-Payments would be the replacement for $all for the Payments context, and you get a sequential event numbering there as a bonus, so you don’t need to deal with commit positions.
I’ve seen that stream naming convention used but not really explained very well. Other than the obvious ability for a human to decipher the name, is there a technical reason to name streams this way?
The standard projection in ES will create category streams based on the stream name split at the first hyphen.