Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
I asked you for your questions about Event Sourcing and CQRS. I took some of those questions to Greg Young for answers about frameworks, Legacy Systems, Use Cases, Projections, Eventual Consistency, and Versioning.
YouTube
Check out my YouTube channel, where I post all kinds of content accompanying my posts, including this video showing everything in this post.
Makes sure to watch the video for all of Greg’s answers. I will put some thoughts together about each of the questions that people on YouTube, Patreon, and Discord asked.
Frameworks
Greg has mentioned that he doesn’t think that CQRS requires a framework. I agree with this statement but understand why some people are often confused.
I’ve found that a good majority of people are confused about CQRS for two reasons. First, they conflate CQRS with Event Sourcing. They think of them as one of the same when they aren’t. CQRS is about isolating reads from writes into different code paths. Event Sourcing is about using events to record state. Check out my post CQRS Myths: 3 Most Common Misconceptions for more.
Legacy Systems
If you discovered event sourcing or were already aware of it and you’re working within a legacy system that persists current state, how do you go about incorporating event sourcing?
The Strangler Pattern comes to mind. However, I think it goes beyond that. I will assume that when people refer to a legacy system, they talk about a monolith without any logical boundaries. And that’s where I’d start. Start defining logical boundaries and take a small logical boundary or just a portion of it, and then from there, define how you want to persist state. Maybe Event Sourcing is a good fit, or maybe it’s not, but you’ve made a giant win by separating a subset of functionality and the data behind it.
Check out my video HELP! My system is hard to change that talks about this.
Use-Cases
A common question is where (in which domains) event sourcing is applicable. I’ve found where it fits naturally is when the people within the business that understand the domain well naturally speak using events.
For example, when a vehicle is on a trip to pick up and deliver goods, these are often called trip events. The vehicle arrived at the shipper, loaded the freight, departed the shipper, arrived at the consignee, and emptied the freight. These are all events that they aren’t anything technical at all. These are common terms used within the industry.
I’ve found when people naturally talk in events, it’s often at the core of the domain you’re working in.
Queries & Commands
Can you use a query within a command, often for validation purposes? In other words, could use an existing read model (projection) that is eventually consistent when executing a command.
While this question comes up often, the answer is pretty straightforward. Yes, so a long as you don’t need to be fully consistent. Your read model will be stale if it’s being built asynchronously. If it is, then if you use it to query to impose some invariant when executing a command, then you need to be fine with it being stale. If it cannot be stale, then you can’t use it.
Eventual Consistency
This was my favorite part of the discussion I had with Greg. eventual consistency is always brought up with asynchronous projections and UX. I’ve done a post about Eventual Consistency is a UX Nightmare that provides some solutions, but this conversation took a different route talking about non-linearized timelines. Typically I’ve always been thinking about linearized event streams, but you might not always be. Check out this talk from “want don’t You consistency no stinking“. After you start watching the talk, the title will start to make sense!
Versioning
Versioning events can be difficult when you’re defining more technical events than domain events that the business actually cares about. I think this is a bit of trap developers can get into with Event Sourcing or using events as notifications. If you model your events after solid and established business concepts, you’re less likely to fully regret defining them. That’s not to say you won’t need to version an event that was based on a business concept. There are many strategies, and the most common is to upcast old events when replaying them to the newest event. Another approach is to really look at the event change and determine if it’s a totally new event that should be defined.
Check out Greg’s e-book Versioning in an Event Sourced System.
Thanks to Greg Young for taking the time to sit down with me and go over what I think are the most common questions related to CQRS and Event Sourcing.
Join!
Developer-level members of my YouTube channel or Patreon get access to a private Discord server to chat with other developers about Software Architecture and Design and access to source code for any working demo application I post on my blog or YouTube. Check out my Patreon or YouTube Membership for more info.