I'm currently playing with DDD & CQRS, and I moved forward a legacy application.
Let's say I have an Article entity, on which I can cast votes.
When a Vote is casted on an Article, I want to increment or decrement a counter accordingly to the value of the vote.
This counter is part of my Query model and thus I don't think it fits the Domain Model, for such reasons, I decided to write a CastArticleVoteService in which I put the business logic about a vote, and I dispatch an Event to be handle by a custom Event Handler which in turns update the counter in a database.
First of all, I was skeptical because I told myself "hey, the process of updating the counter should be in the same transaction as the one which persist the data". But that's obviously wrong if I have polyglot persistence (ie: MySQL / Redis).
However, the transaction stills apply, how could I be sure that the whole event handlers are processed properly and my data are consistent? (here my counter). (what about asynchronous events handler?)
Any tips?
Aggregates define transaction boundaries. When you decide for event-driven architecture then you decide for eventual consistency. So you just have to choose: transaction OR event.
Note that in most cases, eventual consistency is completely fine for the business. That's only devs who have a transactional fetish implanted by RDBMS lectures/brainwash on the university ;)
Alright, here is my take on your question:
In
event driven
&CRQS
architecture, it is also common to useevent sourcing
as a pattern.That means that your votes will not be stored as a counter (
state
), but rather as vote up/down (fact
).In your scenario, to query how many votes an article have accumulated, you can go read all the events related to an aggregate and apply them one by one (in memory) in the order they happened and get a final state of that aggregate instance (
article
).Sometimes when the volume of events are big, a snapshot is kept on the most recent facts resulting from applying those events to an aggregate.
Think of this as the financial equivalent to debit/credit events in a bank. Banks don't just store your balance. They actually store all your transactions, and later do a reconciliation and update your balance.
What that gives you out of the box?
Further reading: