Complexity is the Gotcha of Event-driven Architecture • David Boyne • GOTO 2024 (Category Architecture)

Interesting. speech from David BoyneSenior Developer Advocate at AWS, who discusses the advantages and disadvantages of event-driven architecture (EDA). The bottom line is that complexity is inherent in event-driven architecture right from the start, but if you use the right approaches, then as the system grows, this complexity does not increase as quickly as with other design approaches. The author’s own presentation is as follows: First, he talks about the potential of EDA - how EDA makes architecture evolutionary rather than static.) Then he talks about guardrails to deal with the complexity of EDA.

• How do you fuck with EDA?

The potential of EDA can be seen by plotting on two axes: size and time. Next, the graph shows the decisions that need to be made, as well as the knowledge that we have for this. The bottom line is that at the beginning of the project, we have little knowledge, and we have to make big decisions. It's calledproject paradoxonWe need to be able to postpone big decisions until we get the right amount of knowledge ... or learn faster. But when we make decisions without the right amount of knowledge, we often find ourselves in a static architecture characterized by properties: tightly coupled, low cohesion, resistance to experimentation, team interdependency. In contrast, the author argues that the use of EDA allows you to create an evolutionary architecture. (As in "Building Evolutionary Architecture" here)It has properties like loosely coupled, high cohesion, platform to experiment, team dependency. And she is. Allows you to create components that can be changed depending on the situation. Improves code quality and allows experimentation. It can lead to innovation, but it also increases complexity.

Next, the author shows how to identify events, and then how to start exchanging them between producers and consumers. Then it all starts to evolve and it's easy to get hell out of different events, different producers and consumers and with no understanding of how it all works:) To solve these problems, the author proposes to use guardrails

1. Behavior vs implementation Start not with the details of the implementation, but with the behavior of the system. Here the author recalls about Alberto Brandolini and his approach Event storming, which I have already mentioned. remembered. This technique allows you to start with events inside the system, and eventually understand its behavior and at the same time understand bounded contexts:)
2. Event evolution strategy When starting an EDA project, you need to think about the evolution of events. The author cites a metaphor that events tell a story and tables describe states right now. The author proposes to control the complexity of the event scheme through backward compatibility, optional fields and parallel versions of events.
3. Define coupling strategy This can be done through the use of the conformist, ACL approaches in consumerists. (anti-corruption layer) open-host principle (well described in the book "Learning DDD", more here). The author proposes to separate public and private events within the domain or between them.

But the biggest problem is that there is a mantra.

Producers should not know about consumers This makes it impossible to control the system as it evolves. Therefore, the author suggests using the following tools:

• cloudevents Specification for a general description of event data.
• AsyncAPI OpenAPI for asynchronous APIs
• EventCatalog.dev An open source project with a description that helps document messages, commands, requests and events, as well as create versions of domains and services.

Finally, the author says that complexity will be present regardless of whether you like it or not, and that it is important to be able to cope with it ... with guardrails.

#Architecture #SoftwareArchitecture #DDD #SystemDesign #DistributedSystems