Member-only story
The Event-driven architecture style may seem simple to adopt, but on the field it could lead to conceptual issues. The main issue about events lies in its purpose. What is the intent of each emitted event? Is it a broadcast or targeting a specific consumer? Who would consume it? Is it a command or just a notification? Does the order of events delivery matter? Is duplication a problem? How about fault tolerance or delivery guarantee? Let’s try to get answers to those questions.
Related articles:
- Software Architecture — principles, rules and styles
- Event-Driven Architecture
- Service-Oriented Architecture (SOA)
- Microservices Architecture — a step further than just SOA
- Hexagonal architecture
Introduction
If there is a lack of governance from an architecture point of view, then there will be hidden problems, as teams won’t easily find the source of truth about events. Typically teams who produce should define and document what are events that are produce. Besides, events should reprints domain events, so they should be understood and known by anyone whos needs to consume the. The owner team (if not architect) should be there to aid and make sure to make events visible with purpose.
