I see a lot of new terms like Command-Event, Event-Based Compute, etc., presented around Event-Driven Architecture. Let me clear that up because there are no such things. The real split is Event-Driven Architecture vs Messaging. Event-Driven Architecture is about the logical composition of our workflow. We're using events as the glue checkpoints of our workflow. The key aspect is to model them, so we're broadcasting information, not requesting operations. It doesn't have to be asynchronous; it doesn't have to use tooling like Kafka, Rabbit, SQS, etc. It's about the composition of our flows and structuring our architecture. Events are messages, but they're not the only type of message. The second most important is Command. They differ by intention. The command is an intent to do something. It's directed, and the handler may reject it. Events are facts; they can (and should) have multiple receivers. Yet, the event producers shouldn't assume getting a response. Understanding this split is essential for proper workflow composition. Still, events and commands do not differ by definition in terms of how they're delivered if they're sync or async. The difference is in intention. Now, here comes Messaging. It's a set of patterns like Outbox, Inbox, Competing Consumers etc., focused on integration between our boundaries (modules, services etc.). So knowing what we'd like to achieve, defining how to do it. For instance, guarantees like at-least-once delivery, ordering, and idempotent handlers. They're technical split. But they're still specific solution agnostic, as messaging tooling implements those patterns. So the flow is: - describe the business workflow and model it using Event-Driven Architecture, - design how to get guarantees and define the expected technical flow using Messaging patterns, - Implement it using technical tools. Please do not mix them, or you'll end up with a hangover! So why we're getting terms like Command-Event, and Event-Based Compute? Because some companies were pushing the EDA buzzwords, Messaging didn't sound sexy enough. They didn't embrace semantics and taught their users. But that doesn't change, that eventually, their users will need to understand that to succeed. Still, if they pushed all marketing into event-based terms, how to tell now that it was wrong? The easiest is to reinvent the wheel and introduce new gibberish terms. So, as devs, we should remember the logical, technical split. And differentiate patterns from implementations. Be critical of what we read. Edit: As this post went viral, I also put it as a regular blog article. If you liked it, read it here: https://lnkd.in/dbGaBaR6 and share with your friends.
Oskar Dudycz
1y
Read also more about the difference between command and event in: https://event-driven.io/en/whats_the_difference_between_event_and_command/
Diego Martin
1y
Great article! I agree the difference is the intention and also in coupling (the 1 to 1 communication in commands and 1 to N in events). But if a command can be rejected or accepted, to me that implies it's a synchronous message (e.g: request/response) because the caller's intention is also to know the result. Events cannot be rejected (they are facts) but can be ignored (i.e: not reacted upon), and that's a big semantic difference. If a command is asynchronous, to me that's just an event dressed as a command (i.e: written in imperative) and I personally avoid it. I would at least consider how the modelling would look like if I wrote that message in past tense. We could call everything "message" and simplify, but it helps capturing the intention of things in its name, and it personally helps me to think that commands are processed synchronously, that a response is needed at caller, even of it only contains a correlation ID for the long term operation it triggered, at least I know the command was not rejected. Unlike with events, with commands the caller cares about the receiver (and knows it).
I think that there are actually more... what about actor frameworks (communicating via message passing), event streams & reactive programming, and few more? The thing is that those ideas were developed independently, in different ecosystems and by different people, solving different problems. There is some overlap between them, not just in terms, but also patterns and concepts, but it's confusing as hell. I think having a little bit of history and wider context may help.
I hope you'll forgive me the shameless plug but I think it reinforces your point: https://slidr.io/azzazzel/demystifying-event-related-software-concepts-and-methodologies
Basil Thomas
1y
Excellent Article!!! Before looking at Event Driven Architecture, you really should have a good handle on how those events are generated BEFORE being used to drive your architecture. Events are nearly always in the past tense so something must have happened in order to generate those events. I think CQRS is a one good example of a high level architecture that uses an event driven pattern when commands generate state change domain events and these are then published to be consumed by some kind of event workflow regardless of complexity. In this way, implementation details such as sync or async are handled at the design pattern level and keep your high level architecture more abstract and simplified and more concerned about your business model which really is all about application behavior and state where...CQRS architecture basically excels. Make sure of your architectural model BEFORE your implementation design pattern details is how good software can be engineered for long term success!!
Great explanation!!!... adding the blogpost to my to-read list!
Anyone familiar with messaging and learning about Event Driven should read this. When I say "eventing is a specialisation of pub/sub messaging" I often see raised eyebrows. It is from the broker point of view, but it's very different from a design/pattern point of view.
Ben Lopez
1y
I think those concepts get created when we fail to break the old patterns in place, so we attempt to move into EDA, but as we fail to fully switch, it's just parts of it that get done hence a name is needed to describe the result. Thanks for the clarification and sharing (=
Event Sourcerer / Helping others build Event-Driven systems
1yAs this post went viral, I also put it as a regular blog article. If you liked it, read it here: https://event-driven.io/en/dont_let_event_driven_architecture_buzzwords_fool_you/ and share it with your friends. 🙂