One of the hardest concepts to learn and then over or come is "How do I query events?"
The question in itself shows a disconnect from the concept of what events in an event sourced or CQRS application are there for. In short... you don't query them, BUT... when you are faced with an architect or CTO with a solid grounding in the RDBMS world how do you sell event sourcing... smoke and mirrors is the best way to explain a high-level understanding. Just to be clear we're talking a very, VERY high level explanation. One so high it glosses over several concepts and ALL implementation concerns that it doesn't scare them off. It simple wets their toes in a friendly way that lets the rest of the conversations that are needed happen.
So, how exactly do you explain this?
You start by explaining that an event-store is like (but avoid the fact that it isn't) a master database in a master/slave configuration. Events are written into a master like database (or store as we'll call them now) and queries are then executed on a replicated, slave like database/store.
Avoid the details on how this operates, that's an implementation concern that first requires a conversation on the CAP theorem. Remember to mention that you are talking about the high level concepts, and that depending on what platform, patterns, frameworks and/or persistence technologies (Sql vs NoSQL) that will be used will all influence the answer in such a way that it's a little premature to speculate exactly how it will be implemented.
Here's is an excellent illustration that covers very high level concepts with just a few low level (the example/sample commands and queries illustrated) details.
taken from CQRS & EVS with MongoDb
No comments:
Post a Comment