Aggregates, Sagas and an unresolved concurrency issue

( This was issue #33 of the Event Modeling and Event Sourcing Newsletter - make sure to subscribe! )

Recently, I was asked how I would model the Bank Account example by someone learning Event Sourcing. His attempt was far too complicated – aggregates all over the place, two sagas, and an unresolved concurrency issue… let’s have a look if that can be simplified.

In the last few days, there were also lot of discussions about how to model and build the bank account example, especially together with DBC ( Dynamic Consistency Boundary ).

Some were right, some were interesting, many were a bit too complicated..

Here on LinkedIn ( make sure to read the comments, some good discussions )

Here in an article by Ralf Westphal focusing on the consistency part ( good read! )

And also of course the discussion I had with a colleague, which resulted in the model you see now.

Let´s clear one thing first - if you´ve never heard about DCB, you either live under a rock or you are just getting started in Event Sourcing ( just kidding.. ). It´s the one thing everybody seems to be talking about these days, and I agree, it´s a big thing.

There is chapter 44 about DCB in my book “Understanding Eventsourcing” ( if you subscribed to the Newsletter, you received a Voucher, don´t miss that ), or you an dive into the topic using the official page under https://dcb.events/

DCB is about consistency, it´s not about information flow. So if you model a system, it will look similar using DCB or not ( DCB might have fewer events, that´s all )

Looking at the information flow, I typically just try to model what might happen step by step - not thinking at all about technology, implementation patterns or aggregates. Moving money is not one Transaction, it happens in several steps. ( I´m not a financial expert - correct me if I´m wrong )

1) Open Account

2) Request transfer from Account A to Account B ( no money is moving yet )

3) Process the transfer and move the money to the other Account ( this is where money is flowing )

4) Close the transfer ( final step )

Do you need a “Money Transfer” Aggregate? It´s not wrong, but it´s also not absolutely necessary. Of course there are different ways to model the flow and this is my attempt ( which came out of a recent discussion with a colleague )

I´m not claiming that this is the “perfect” model, but the simplistic way I would approach it. Feel free to comment, happy to discuss the details.

Want to see this in action? I made a short Video, how to run this example as a Prototype.

Best regards,

Martin

If your project is drowning in unclear requirements, your meetings are just firefighting sessions, and deadlines are creeping closer while velocity keeps dropping – maybe I can help and provide some clarity.

Often, finding the real bottlenecks unties the knot. That’s exactly what we do in my new offer: a 90-minute CTO Call to quickly gain deep clarity.

You can book it here.