A common issue I see is understanding the flow of commands, events and queries within a typical CQRS ES based system. The following post is designed to clear up what happens at each step. Hopefully, this will help you to reason about your code and what each part does.
Making mistakes is part of programming. Spotting them early can save you time. I’ve started to notice a common set of ‘DDD Mistakes’ which many of us seem to make. And yes, I’ve made them all at some point in my career. This is by no means the definitive list – I’m sure there are more.
This question keeps cropping up. How do you handle set based consistency validation in CQRS. In fact, one of my subscribers had this scenario:
“I have a user registration system with login/password. The login must be unique in the system. How do I implement such a requirement?”
Just in case you are not familiar with CQRS and ES, this problem arises because of something called ‘eventual consistency’.Continue reading
The real power of eventstorming is how it focuses on outcomes, not activities.
Why is this powerful?
It gives you options. That is according to Dan North at his recent talk at DDD eXchange in London with Skill Matter.
I know there is a lot of interest in eventstorming right now. It is of particular relevance to you if you are using DDD, CQRS and Event Sourcing. So I’ve written up my notes from Dan’s talk here. I hope you find them useful.
Any of these sound familiar?
Rubbish in rubbish out.
Never trust user input.
If you’ve ever built any sort of professional application you will have had to validate user input. Whether it is to ensure a valid email address or something more complicated. There are tried and tested ‘rules’ for doing this safely while being nice the user.
- Validate on the client side – makes for a better user experience
- And validated on the server – never trust user input
But here’s a question..
If you issue commands rather than send in models, where should the validation occur?
The most obvious answer is in the domain model.
But this poses a problem…Continue reading
The pen is mightier than the sword. Or so they say. However, this smart LiveScribe 3 pen may just be mightier.
Picture a typical meeting…
You’ve got a whiteboard, notepad, your phone and hopefully the right people in the room. You may even have some funky planning poker cards*.
All good so far.
Now if you are into domain driven design, the chance are you’re going to want to get involved in the meeting. Listen closely to the language used and try to deepen your understanding of the domain. Or at least that’s what you’re supposed to be doing!Continue reading
C# private fields are not accessible outside the class. It’s C# 101 right?
Which means this code should not work…
Oh the irony.
The DDD community advocates for unambiguous language. And yet even our own terms are heavily overloaded. Whether it’s on stackoverflow like here or on the DDD/CQRS google group like here.
So, just to be clear …
… a CQRS command is not the same as the Gang Of Four Command Pattern.
But what are the differences and how best to use them? This is what I’ll cover in this post.
Where do you put code for sending emails? Sounds simple right? The funny thing is that if you’re adding it to a CQRS system it can be a little tricky.
It all depends on when you send them. Too early and other processes may fail and you end up sending your email half cocked. And don’t forget event replay. Could be a bit embarrassing re-sending all the emails since your app launched. I was a hairs whisker away from doing just that once!
So, in a CQRS ES system, where do you put the code to send the emails?Continue reading
Events are at the heart of a CQRS Event Sourced system. Which is why changing or upgrading them can be problematic. In this post I’m going to cover a few principles to bear in mind, which should help you avoid hitting the rocks. Before I dive into ‘how to upgrade CQRS events’ I’m going to recap the role Events play in the system.Continue reading