I recently came across a blog post on/about EventStoreDb with the catchphrase to keep streams as short as possible (at least this is how I understood the post).
This made me think about the following scenario where I’d like to know, if this is a valid approach (means: does it make sense at all)?
Given a domain entity Location
with the events LocationAdded
, LocationEdited
(for simplicity in this case: the entity is always updated completely in one event), LocationPublished
and LocationDeleted
. Each event carries an entity id. All events are put into the same stream - e.g. location
. Additionally there is a separate read model database with a database entity that matches this domain entity.
I would now create a projection that partitions the events by the entity id within the event. The projection keeps the current state of the location and hence updates the state with the data from the processed events. Finally, the projection outputs to (outputTo
) a stream location_{0}
.
I have a worker process running which subscribes to $all
(or similar) with filter on location_*
and simply puts the content of each stream event to the read model database.
Is this a valid approach? Or would it make more sense to have the worker subscribe to location
instead and process the events on its own in order to avoid multiple streams / multiple projections (as this could be used for other domain entities as well)?