Maybe I'm missing the advantages but I never quite understand the whole interview and job match thing where they want to find someone who did X Y Z exactly like they want to do it.... and if they didn't they're a bad fit.
Outside of some special ultra deep technical cases... that seems like a weird thing to require and just to assume they would be bad doing it your way seems off....
@bastianrob what country are you living in?
Command-Query-Separation - seperate mutators (command) from readers (query)
Command Query Responsibility Segregation -
Nitpicky implementation of CQS. Nitpicky since it requires to have a split model system - one for commands (mutators), one for queries (readers).
ES means Event Sourcing.
God. So many abbreviations.
While I like the essence of the rant, it lacks in term of why CQRS is FAR more than a split in read | write.
Could you elaborate?
CQRS with ES is about separating updates and commutation of the individual operations in an eventually consistent fashion using commands and events. Commands write an event to the event store. It's first and foremost a DDD formalism, without a strong concrete domain it's not particularly useful.
Unlike CQS, CRQS+ES will utilize event denormalizers to take series of events they care about (aggregate identity relative), process the current sequence of events into an aggregation that represents the current state.
If you need fully consistent data, you expose interfaces that load from the event store based on aggregate id.
For data that doesn't need to be fully consistent, the query store exposes pulls data in its most eventually consistent state from the query store. The query store is generally read domain optimized.
The first rule of CQRS+ES, is you probably don't need CQRS+ES. And even when you do, most orgs I've seen try to use it didn't have enough understanding of their domain or processes to make it work properly.
@IntrusionCM The post is just a rant. Not trying to preach about CQRS+ES.
My specific implementation of CQRS is that READ have its own database.
Two to be exact.
1 for Public facing website which is stored in ElasticSearch
1 for Internal business site.
Let's call these, ReadModels DB
Both have their own microservices.
On the write side.
- There is 1 database for EventStore.
- Command produce event which is stored in event store
- Triggers an event to message broker
- Which is then listened by every READ side services and updates their own readmodel db.
- I go further as separating READ and WRITE services physically. Giving write side less resource than read.
There's a public facing API gateway which exposes all READ side services.
Data team can reinterpret the data stored in EventStore.
Engineering team can replay the event and get state of data at any given time.
Business team can run through the history and detect any fraudulent activity.
@SortOfTested I know all of that.
I was curious wether bastianrob could explain it.
Because from a database standpoint, Event Sourcing can (and you explained it very good) has no explicit transactional state.
You get the last known working state, as in replaying all events that occured and then applying them to get the end result.
This can be cumbersome. Many specialized systems utilize snapshotting to have a certain state ready and built upon snapshots a "semi transactional" state.
Event sourcing is an Audit Log / VCS - it generates tons of data.
It's one of the reasons why it's very cumbersome.
CQRS can be implemented in different ways, eg with a denormalized NoSQL backend for reads and an SQL backend for writes. Requires synchronization... Still cumbersome, but more manageable.
I found some hints in bastianrobs rant that made me question wether he fully understood the consequences.
And the abbreviation thing is just a nitpicky - it leaves a bad taste in my mouth, since abbreviations can mean a lot of different things.
TLDR: bastianrob - Event sourcing / CQRS has consequences. And I can understand why it's an very unusual choice for most projects. Unless you need auditing, it's overkill. Even when you leave ES out.
Def don't have to tell me, I've implemented them at scale.
I do agree with his point about redux being overengineering for most applications. It's also somehow simultaneously shit engineering, one step removed from a god object, has no support for tombstoning and makes me want to punch kittens when I observe it's memory footprint. I wish people would learn rxjs and stop launching failboats.
There's a good chance from what I read that they passed because he challenged their knowledge, and that makes bad leaders defensive.
*Continues to talk about Rob like he isn't even in the room 😋
@IntrusionCM The core of why ES is needed is that the company needed to audit and track every changes made to the data to make sure no foul play done by Operations.
The core of why using CQRS is because the company needed the data in ElasticSearch or read side things to be eventually consistent with the SSOT.
Maybe testing my skill gets you off...
But the core of the rant is not about preaching CQRS+ES.
It's about quick to be judged to do overengineering. While those who accuse to, applies similar principle without even knowing it.
@bastianrob it was less about testing your skill set.
And as I said: I like the rant. And I definitely agree with your point about overengineering.
You wrote a very dense rant - dense in the sense of a lot of information compressed.
It was not only about testing your skill set - I wanted to decompress your rant a bit and give you a subtle hint that writing in such a dense way makes it hard to follow.
Just setting the abbreviations fixed at the beginning would have made this rant something I'd hang up on my wall (not joking).
I see many rants as an opportunity to learn stuff.
And especially in this rant _is a lot to learn_.
Thank you :)
ambermckinney041dI like equity not equality.
Last week I read an article on about this topic
stacked279641dThis sounds like a typical interview where they check whether they agree with you or not, rather than testing your skills. Don't be too harsh with them: doing a good job at interviewing, just like software development, requires some practice and it's not as obvious as it seems.