I’ll update this post with the link to the screenshot and the slide deck when Sergio posts it.
Update: here they are.
On a scale of 1 to 10, without thinking too much about it, I would give myself a 4 or a 5 on this one, and for a couple of (somewhat related) reasons:
- - a fundamental flaw of the presentation is that I was trying to give a high-level summary overview of the things that Udi and Greg and Mark are talking about, without having the benefit of the width and breadth of their knowledge and experience of actually implementing it in multiple situations (as I mention in the talk, I do hope to have a system in production this year that implements a fairly robust version of cqrs, but even if I’m successful, that’s still quite a bit short of having done it for years in highly scaled environments).
- mild digression: Bellware, in a post to the alt.net mailing list a while ago, made a point about something he called “Talking with a Full Mouth” which, to crudely paraphrase it, was that you shouldn’t try to ‘educate’ people about software practices unless you’ve practiced them for years, and in fact, should really just STFU about it. As someone who was paid to educate people about philosophy and logic in a previous career, there is something to this. There were times when I might sit in on other people’s classes, and there were times when it was painful because the educator didn’t have a firm grasp of the subject matter and I felt the class suffered from it. I don’t feel too bad about the presentation in this regard because I was very clear about what I was doing, giving a high-level summary overview of what CQRS was about, but didn’t have all the answers, and pointed them to the authoritative sources. When I was teaching students about, say, Utilitarianism, there’s no way that I could claim to be as intelligent as Mill, but that didn’t mean I couldn’t explain to beginning philosophy students the difference between Act and Rule Utilitarianism.
- - I don’t have a firm grasp of the right way to do Event Sourcing, which I think is really how CQRS needs to be done. There’s something about how the code I’ve seen that implements it that strikes me as….sub-optimal, for lack of a better term, but I can’t quite but a finger on why it strikes me that way. As I mentioned in the talk, I’m pretty convinced that this is because I don’t quite get it deeply enough. I explicitly made this point, and so, like dogs sensing fear, a number of the questions focused on this area.
- - You can’t really explain any topic in-depth in an hour, much less CQRS.
- - Half of the purpose of the presentation was, frankly, to have people react to how I presented it, and ask questions that I might not be able to answer, not only to guide how I continue my blog posts about it, but, more selfishly, guide me in terms of what I need to work on more deeply to increase the chance of success of my own implementation of it. So, mission accomplished there.
Other than that, I thought it went well.
Anyway, I think that one of the things that is much clearer from the talk is that the importance and attractiveness of CQRS is tied into a couple of crucial areas:
- - having scalability built in: a couple of comments that people made to me during and/or after the talk was about how they wished they had something like CQRS in previous projects to handle scalability. Short of violating laws of logic and/or physics (some laws of physics appear to violate laws of logic, which is why they are probably false, but not even I can digress that point here), nothing is impossible, but trying to retrofit CQRS into an existing software system/application appears to be, well, really really hard. So, if you’ve paid a price in the past for not having scalability you didn’t know you needed, CQRS will seem, at least on the surface, more attractive.
- - having an audit log built in: the conceptual idea of having an exact record of everything that has happened in your system over time is something that has incredible appeal. Almost any system of significance runs into the problem of trying to figure out the answer to the question, “How did the application get to this state?” Whether you are a developer or an operations manager, a hell of a lot of time can end up being spent trying to determine this. Even a system that doesn’t technically have bugs can end up in a state that the end users didn’t expect. When constructed properly, a CQRS-system at least offers the promise of being able to answer this question. You can figure out how you got to the state you are in by examining the record of the events that got you there. In theory, you can set up a UAT environment and replay those events, debug them closely, and see exactly how you got there. In theory, if you construct the system properly, you can rollback those events that got you into the state you don’t want to one that you do want. In theory, as you develop new code, you can replay events (and possibly even commands, more on this below) and see what the effects of the new code will be on events that have already occurred. All of these things will appeal to people who have had to deal with this.
- - Eventual Consistency: do you understand the concept and does it apply to your system? Do you accept the notion that all data is stale? At the highest-level, I think this can be seen as a deal breaker. It’s one thing to accept the idea that, say, Amazon has no choice but to deal with this, yet another to think that your own system, which really will never need to scale to Amazon levels, has to deal with it.
My own list of questions that I wrote down after the presentation are around the following:
- - if, as a Customer, I change my Address information, I expect to see that the information is updated when I press that Submit button. But if my screen is populated from data from my eventually consistent data store which is gathered from my Query layer, how do I ensure this? In an eCommerce situation, Order Submission is a question here. I expect to see the Order ID (or whatever) on the Order Confirmation screen after I press that Submit button, especially since I’m often asked to print out the Order Confirmation screen. When I was part of a team that handled sales for the eCommerce store for the NBA, we sold a hell of a lot of product in the seconds/minutes/hours after the Lakers clinched their 3rd title (I think that’s when it was). Eventual consistency in terms of getting an Order Confirmation email is one thing. As an end user, if it takes a minute or three to get that confirmation email, that’s expected. But while placing the order, I expect that Order ID to be there ‘immediately.’ How do I ensure that this happens? My Query Layer might query the Domain directly because my system issues an ReallyImportantOrderThatHasToBeReflectedImmediately query, but is this a well-thought out architecture or a hack? In other words, what’s the well-thought out way of handling Eventual Consistency for those UI queries that just have to be consistent, especially in situations of high traffic?
- - Commands issued from the UI become Internal Events that are saved to an Event Store that produces External Events that are published. How exactly should this work?
- - Should there also be a Command Store, as well as an Event Store? I’ve not seen any discussion about this, but it seems like you might want to have this, if only so that you can replay commands against a future code base to see what the effects are. You want the Event Store as your audit log, and because you want to replay them given the business rules of your Domain at the time they occurred, but why wouldn’t you also want to have the Commands themselves recorded so that you can replay them given new business rules? Or can the Event Store inherently handle that?
And I’m sure there are others.
In any event (pun intended), I hope that my presentation at least got some people to be interested in CQRS, and thinking about if it might work for them.