4 ms·

At work (consulting/development shop), we went far down this path a few years ago. Conclusions: 1. CQRS+ES works great, if you implement it carefully, which re

At work (consulting/development shop), we went far down this path a few years ago. Conclusions: 1. CQRS+ES works great, if you implement it carefully, which requires discipline. We ended up creating our own framework (ugh) to make it easy to go down the right path. 2. There are trade-offs, of course. 3. You are only one smart agile thinker-in-a-pinch away from stepping away from the discipline and creating really tricky complexity and far more negative trade-offs. 4. There is very little market demand for this approach among the typical enterprise business solutions we work on; though as I understand there are some sharp peaks in certain areas of financial services. (The odd thing is... we have financial service customers, just not in the particular domains where there is demand for CQRS.)

k__ 6y ago
What were the biggest issues with it?
born_a_skeptic 6y ago
What aspect of Financial Services? Trading?
- dsies 6y ago
  In my experience, lots of banking, some trading. In both cases, it is used for history, audit and precision. The idea is that for banking, it is not enough to just get the _current_ state - the more important thing is how someone _reached_ that state. Adding history to transactions is not new - so rather than bolting on a history/audit mechanism, you knock out both - a higher resilience, distributed system + built-in audit/history mechanism.
crispyambulance 6y ago
> You are only one smart agile thinker-in-a-pinch away from stepping away from the discipline and creating really tricky complexity and far more negative trade-offs. I love this sentence. That seems to be a common pitfall, regardless of framework or pattern, which ironically puts a hero aura around the person who did it.
fmax30 6y ago
I agree with most of your points. We also went down this path (CQRS + ES) a few years ago at my old company. Implementing it was fun, but it did add quite some complexity. Granted, it was very scalable. Interestingly enough we used it for an enterprise messaging app, although I left for other things before it was released. I wonder how that codes looks today.

k__ 6y ago

What were the biggest issues with it?

born_a_skeptic 6y ago

What aspect of Financial Services? Trading?

dsies 6y ago
In my experience, lots of banking, some trading. In both cases, it is used for history, audit and precision. The idea is that for banking, it is not enough to just get the _current_ state - the more important thing is how someone _reached_ that state. Adding history to transactions is not new - so rather than bolting on a history/audit mechanism, you knock out both - a higher resilience, distributed system + built-in audit/history mechanism.

crispyambulance 6y ago

> You are only one smart agile thinker-in-a-pinch away from stepping away from the discipline and creating really tricky complexity and far more negative trade-offs. I love this sentence. That seems to be a common pitfall, regardless of framework or pattern, which ironically puts a hero aura around the person who did it.

fmax30 6y ago

I agree with most of your points. We also went down this path (CQRS + ES) a few years ago at my old company. Implementing it was fun, but it did add quite some complexity. Granted, it was very scalable. Interestingly enough we used it for an enterprise messaging app, although I left for other things before it was released. I wonder how that codes looks today.