AggregateID / Aggregate for Event Stream

EventStoreDB
#1

Hi
Recently I started studying DDD and Event Sourcing.
However I am bit confused while creating a stream in event store.

As an aggregate instance encompasses a transnational boundary, sometimes I feel having a stream for an individual aggregate instance with aggregate id would be good. But then creating lot of streams in the process pose a dilemma in my mind. I feel I might end up creating clutters in the store.
So not sure whether just one stream for one aggregate is a good option.

If we create a stream with aggregate id that means we need to have a subscription against each stream.
That also increase the number of subscriptions in Event Store.

Another point is if we have multiple listeners to the event, is catch up subscriptions the way to go?

I am looking forward to suggestion on how everyone think about it. I appreciate your help.

#2

A stream per aggregate is a common pattern so it’s a good option. You don’t have to subscribe to each stream individually. More often it will make sense to just subscribe to the $all stream and filter out the events that you care about.

#3

Hi Mat,

Thanks for the reply.

You mean one stream per aggregate instance. So if I have five books of aggregate Book, I will have five different streams for that catering every books instance.

One more thing if I can make my projections subscribe to each streams that are created, I think it can help me handling the set of events pertinent to that aggregate instance only. I don’t have to deal with other events, right ? will that pose any problem if I implement that way.

#4

Why would you need to subscribe to each aggregate stream? There’s rarely a need to process events from a single aggregate instance only.

#5

Hi,

If I have a subscriber for that aggregate stream only, it will get events only when an event written to it. It doesn’t have to bother about events written on other stream for other aggregate instance.
The filtering out of odd events can be done by the system.
We can fast processing the read models in turn of it.

This is my assumptions.
If am going completely wrong way, kindly let me know.

Thanks for the reply.

#6

I never heard of such things like a read model for a single aggregate. How do you see it working? I’d suggest watching our previous webinars, at least two of them have something to learn about projections.

#7

I did not want to mean read model for a single aggregate. There will be one read model for one type of aggregate.
But I was thinking if we have multiple subscriptions for one type aggregate with multiple instances it might increase the concurrent updating potentiality of the read model.
Updating a particular aggregate instance should not have to be made synchronous. I can update other instance of same type and at the same time.
Not sure how exactly internally event store behaves though.

Thanks for the reply and looking forward to it again.

Webinars are good. I will definitely try to access them.

#8

There’s no point having one subscription per aggregate. You will end up in subscription maintenance hell, I am not even sure how this would be possible. If you have 100K aggregates, will you have 100K subscriptions?

In addition, read models are not to project the aggregate state. Why would you do that? CQRS states that the query model has little to do with the command model. The command model is your domain model. The query model should be optimised to answer questions that might or might not be related to the structure of your aggregates (most of the time not).

Really, spend some time watching our webinars. We will also update the docs. If you are in .NET space, get hold on my book, there’s a lot of code there and quite a few pages dedicated to projections. It’s basically an event sourcing book, no matter what the title states.

1 Like
#9

Thanks a lot for your advice. It will definitely add values to my learning.
You have explained every thing in the first para of your reply.
Just to keep things simple I used the term aggregate in read models, I should have been more careful.
I wanted to mean if I start receiving data of command models of same type and at the same time will it help me to update the read models in a concurrent manner.

Last but not the least if in my application read model simple enough to expect almost the same structure as of aggregate, is it necessary to bring complexities for sake of making them grossly different ?

#10

Well, if your query side replicates the command side, I’d say you simply aren’t getting the fundamental benefit of CQRS. I’ve done this before and I clearly see it as one of the most common mistakes.

1 Like