My aggregate root needs to read and apply the events only for the current entityId. How can I read these from Eventstore and filter on entityId? I use the .Net API.
use a stream name of the aggregate id then just read the stream.
ok, I see now that it seems to be a practice to let the stream name be a function of the aggregate’s identity. A bit weird at first thought, I must admit:)
How else would you load the events for a particular aggregate on request?
I have to admit I get a bit stuck on this as well, not because I want to economize on streams, but I do want to economize on round trips.
I have a stream called ‘teams’, and when I build state from the events, I make each team a key in the teams object.
I hope I don’t regret this decision, but it is hard to imagine good economy in building a list of 50-200 teams by making 50-200 server requests.
Is there a standard set of pros/cons you go through over these kinds of trade-offs?
This is more about modeling aggregates than about eventstore. How would you model things in a document database?
Collection = teams. There would be a document record for each team.
– (still learning aggregate terms and principles… went back to http://vaughnvernon.co/?p=879 before this reply. 
)
But with that I could make one query to make a list for the view.
The need for (1-n) server requests per stream factors into any preference I am otherwise inclined to implement like one stream er team entity.
You can have one stream per aggregate
or
one stream containing all the same Domain events with the $correlationId set in the event’s metadata
https://eventstore.org/docs/server/4.0.0/metadata-and-reserved-names/
A view is usually populated from a readmodel.
If you want to do it 100% eventstore there are a couple of options:
-
Read from $ce-team (built in projection by category)
-
Create a custom projection stream with only necessary events.
-
Create a custom projection with state.
Aggregate equals stream. It’s totally fine to model it in other ways, but then it’s not an aggregate.
/Peter