Most of the time, we justify Event Driven Architecture with performance issue. So we believe it only fits for really complex software.
In my humble opinion, this is a mistake. As every craftsman, performance optimization is the last thing I try to do, after having a working code, and after having a clean code (which imply that I very rarely need to care about performance). Still, I find Event Driven Architecture really valuable, really early in the project.
As we know, test coverage is a side effect of doing TDD. The main purpose is that it improves your design. In the same way, good performance is a side effect of an Event Driven Architecture. The main purpose is that it leads to a very decoupled, and Domain centric design.
Because drive your architecture with events will help you to be really aligned with the needs of your business domain. It is not an accident if event driven architecture is hardly pushed by the Domain Driven Design (DDD) community. Especially Command And Query Responsibility Segregation coupled with Event Sourcing (but don’t forget it’s only an example of an Event Driven Architecture implementation).
Think about it, what better than a flow of events between entities to describe an actual business process? It is really close of what happened in real life. Let’s say you want to manage a car rent process. When a customer rent a car, the event for the business is that a car is rent.
It could be interesting for several business units (let’s call them “entities”): the car store, because it could possibly need to inform us if no more cars are available. The bill, because the customer has to pay for the rent. Any insurances because they have to know which customer is driving the car…
So you will code this CarRent event, it will be publish somehow by the CarStore entity when a customer want to rent a car:
CarStore.Rent(CustomerId)
And other entities like bill will subscribe to this event to generate a pdf with the price for the customer:
Bill.Handle(CarRent))
As soon as you include the domain entities and events in your code, it became very natural to speak with your stakeholders. Because you speak the same ubiquitous language, and this language is just naturally embraced in your codebase.
Even better: as your code is a really good modelisation of the actual process, you will be able to find easily if there is something strange or not logical in the process. It will help you to understand the business, and thus to provide more value for them.
When you are using an event driven architecture, CQRS and ES come naturally as concrete possible implementation, because they are really convenient ways to manage events. But the fact that you built your system with CQRS/ES is not important, it is a technical thing.
What really matters are the events, because it will help your code to be a really good representation of your business domain.