Event Sourcing - stream design

mslot_21199 0
Viewed 96

I am sitting here looking into CQRS and event sourcing, really interesting topics. When it comes to stream design, and and aggregate roots, i feel a bit left in the dark. How do you do it?

Lets imagine that i have an UI, where i can add stuff to a basket, generating a lines in a basket.

Would I have:

  1. a stream pr basket (with basic info attached, like shipping details, name, email etc)
  2. a stream pr basketline

So i would have many streams

  • streams/basket-[basketid]
  • streams/basketline-[basketid]

Basically i only send the minimal data over the wire.

or would i simply have one stream

  1. stream/basket-[basketid]

And every time i add a line to my basket, i send the whole basket over the wire.

As i understand it, it is best to have one to many streams, and not one big streams/basket stream. Or am I mistaken here as well?

My focus here is streams. Any "best practices" on this kind of design: Links, books etc would be appriciated.

event-sourcing cqrs
1 Answers

How do you do it?

Start by watching All Our Aggregates are Wrong (Mauro Servienti, 2019), which considers the question of how many different aggregates you might need to represent a digital shopping cart.

I tend to think of aggregates as graphs of information - if two pieces of information must change together (A changes, and therefore B must also change RIGHT NOW; or A can't change, because its range of allowed values is constrained by B), then they belong to the same aggregate. The boundary of the aggregate separates information that is tightly coupled together from everything else.

Because distributed transactions are hard, it follows that we want our aggregates stored in such a way that changing an aggregate only requires holding one single lock. For example, we won't normally spread a single instance of an aggregate across multiple databases, because ensuring that all of the databases change in exactly the right way at the "same" time is really hard.

We normally store all of the information that is tightly coupled together in a single event stream for exactly the same reason: there's only a single lock to manage.

user_547340
Related