{"id":613532,"date":"2023-03-02T08:49:24","date_gmt":"2023-03-02T14:49:24","guid":{"rendered":"https:\/\/news.sellorbuyhomefast.com\/index.php\/2023\/03\/02\/dont-let-event-driven-architecture-buzzwords-fool-you\/"},"modified":"2023-03-02T08:49:24","modified_gmt":"2023-03-02T14:49:24","slug":"dont-let-event-driven-architecture-buzzwords-fool-you","status":"publish","type":"post","link":"https:\/\/newsycanuse.com\/index.php\/2023\/03\/02\/dont-let-event-driven-architecture-buzzwords-fool-you\/","title":{"rendered":"Don't let Event-Driven Architecture buzzwords fool you"},"content":{"rendered":"
\n


\n
\n <\/span>
\n \"cover\"
\n <\/a>
\n <\/span><\/p>\n

I see a lot of new terms like Command-Event<\/a>, Event-Based Compute<\/a>, etc., presented around Event-Driven Architecture. Let me clear that up because there are no such things.<\/strong><\/p>\n

The real split is Event-Driven Architecture vs Messaging.<\/p>\n

Event-Driven Architecture (EDA<\/em>) is about the logical composition of our workflow.<\/strong> We\u2019re using events as the glue checkpoints of our workflow.<\/p>\n

Contrary to the traditional approach, we focus on verbs instead of nouns. So behaviours in our systems, interactions between them, reactions about new information and data in motion.<\/p>\n

Events are excellent workflow facilitators.<\/strong> They represent facts on what has happened. We\u2019re inverting the classical flow; instead of requesting everything, we\u2019re notifying all interested parties. Then others can react and publish new information through events. That helps to build decoupled and autonomous components<\/a>.<\/p>\n

Events are messages, but they\u2019re not the only message type. The second most important is command<\/em>. They differ by intention.<\/strong> I wrote about it longer in What\u2019s the difference between a command and an event?<\/a>. TLDR:<\/p>\n

A command is an intent to do something. It\u2019s directed, and the handler may reject it.<\/p>\n

Events are facts; they can (and should) have multiple receivers. Yet, the event producers shouldn\u2019t assume getting a response.<\/p>\n

Understanding this split is essential for proper workflow composition.<\/strong> As much as we\u2019d like our flow to be fire and forget, sometimes we need to have an explicit request to do something. Suppose we model workflow so that we always expect a particular event back as a follow-up. Is our event really broadcasted information or just an implicit command?<\/p>\n

Events and commands do not differ by definition in terms of how they\u2019re delivered, whether synchronous or asynchronous.<\/strong> The difference is in intention. The event doesn\u2019t have to be asynchronous or use tooling like Kafka, Rabbit, SQS, etc. It\u2019s about the composition of our flows, modelling conversation and structuring our architecture. It\u2019s close to the original Alan Kay\u2019s definition of Object Oriented Programming<\/a>.<\/p>\n

Now, here we got to Messaging.<\/strong> It\u2019s a set of patterns like Outbox, Inbox, Competing Consumers etc., focused on integration between our boundaries (modules, services etc.).<\/p>\n

EDA and Messaging are different design perspectives.<\/strong> With EDA, you\u2019re shaping your application\u2019s conceptual\/logical split, interactions, and how the flow looks.<\/p>\n

Knowing what we\u2019d like to achieve, we can go one layer down and define how to do it. For instance, how to achieve guarantees like at-least-once delivery, strict ordering, and idempotent handlers. That\u2019s Messaging; it tells how to handle communication efficiently and is part of the solution space. Yet it\u2019s still agnostic to a specific technical solution. We should select the messaging tooling based on the design and whether it supports the Messaging patterns we have chosen to fulfil it.<\/p>\n

The design flow should look like this:<\/strong><\/p>\n

    \n
  1. WHAT?<\/strong> Describe the business workflow and model it using Event-Driven Architecture. That includes communication flow between components, boundaries, etc. Great tools for that are EventStorming<\/a> and Event Modeling<\/a>.<\/li>\n
  2. HOW?<\/strong> Design how to get guarantees and define the expected technical flow using Messaging patterns. They\u2019re already established; no need to reinvent the wheel. Gregor Hohpe curated most of them in Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions<\/a> 20 years ago.<\/li>\n
  3. WITH.<\/strong> Select messaging toolings like RabbitMQ, Kafka, SQS or others that match your requirements. As you see, this is the last phase and outcome of the previous steps.<\/li>\n<\/ol>\n

    Please do not mix them, or you\u2019ll end up with a hangover!<\/strong><\/p>\n

    If we flatten all that into a single perspective, we won\u2019t be able to do a proper design. Without shaping the proper APIs based on intentions, we\u2019ll end up with synchronous, direct communication but made implicitly in an asynchronous way. It is a nightmare to run on production as it\u2019s hard to trace the processes and reason what and why went wrong. That usually ends up as distributed monolith. It\u2019s a dark place with all cons of monolith and microservices but no pros.<\/p>\n

    Still not convinced? Let\u2019s get back to asynchronous commands, then.<\/strong><\/p>\n

    Some people claim that they\u2019re not commands then but events. In my world, how we send commands between modules is part of technical design, so choosing our messaging patterns, tech stack and protocols.<\/p>\n

    If we\u2019re okay with in-proc handling, we can just use in-memory processing and call it a day.<\/p>\n

    If we have a distributed system (e.g., service-oriented architecture, Kubernetes, multiple instances for scaling needs, etc.), we may need better delivery guarantees to ensure that our state is consistent. We may need Outbox Pattern<\/a> or use a durable messaging queue.<\/p>\n

    Still, that choice doesn\u2019t change the message semantics; the intention remains the same.<\/strong> We can use Request\/Reply pattern<\/a> to get the result of the processing. All of the mature messaging toolings like Wolverine<\/a>, NATS JetStream<\/a> or NServiceBus<\/a> provide that out of the box.<\/p>\n

    So why we\u2019re getting terms like Command-Event, and Event-Based Compute?<\/strong> Because some companies were pushing the EDA buzzwords, Messaging didn\u2019t sound sexy enough.<\/p>\n

    They didn\u2019t embrace semantics or teach their users existing patterns because the tooling didn\u2019t support them out of the box. But that doesn\u2019t change the fact that, eventually, their users need to understand that to succeed.<\/p>\n

    Yet, if companies pushed all marketing into event-based terms ignoring existing patterns, how to tell now that they were wrong?<\/p>\n

    The easiest is to reinvent the wheel and introduce new gibberish terms.<\/strong><\/p>\n

    Curtain.<\/strong><\/p>\n

    So, as architects, developers, we should remember to differentiate patterns from implementations. Be critical of what we read.<\/p>\n

    That\u2019s why I want to highlight how it\u2019s important to break our design into multiple layers:<\/p>\n