Want to use events in software development? Here are 5 reasons why you should do it!
In the last years, microservices and distributed systems have gained in popularity, since the problems with monolithic systems began to rise after years of the de-facto standard. Everyone is trying to decouple their systems.
One way to decouple your application is with events.
What are events and why should you use them?
There are different definitions and types of events, but in this context we will refer to events as important milestones / facts in a specific domain. We are talking about domain events.
By using events in our software projects we have several benefits:
- Important business concepts are made explicit.
The pure usage of events, meaning the explicit creation of objects with context-specific meaning, draws a story. Every software developer that is going to open the solution will notice the events and is going to know (if documented properly), what the semantic of this event is.
Also, events help by creating an ubiquitous language that is spoken by developers, managers and domain experts. The ubiquitous language is a core part of domain driven design which is a concept that will help you a lot if you are developing big and complex systems. - Decoupling across different bounded contexts
In a perfect microservice cluster, services shouldn’t go down because of another’s service defect. The whole point of creating microservices is to package functionality that belongs in the same bounded context and communicate through specified interfaces. These specified interfaces are often events that are shared through teams and organizations.
By defining an explicit way to interract with the service through events, we are effectively decoupling our system, since the program-flow will be created dynamically and reactively by the system and is not static.
In a way, we are using the Open-Closed Principle in a higher layer, which is pretty awesome. - Easy testing
You want to test your event handlers?
It’s pretty easy, since the only thing you need to do, is to run the application with the corresponding dependencies registered and fire an event. You could also just test the eventhandlers “handle” method directly, since the “firing” and “consuming” of an event should be tested in the infrastructure layer.
This means, you will have more unit tests and less integration tests, which will also shorten the time of your CI/CD pipeline. - Domain knowledge
The cool thing about events is, that they are storable. By storing your events, you will be able to follow and analyse processes and problems in your systems.
You will also have deeper domain knowledge, since the pure existence of an event (with some metadata that can be attached easily, like the date and time this event was raised), will give you a strong understanding of some business facts.
In case you use event sourcing, time-travel is also possible which is a pretty awesome feature! - Data analysis
When you start storing your domain events, you will accumulate knowledge which is better than every sourvey you will ever do.
By sorting, filtering and analyzing your event streams with data analysis tools, you will be able to make important business decisions.
This also enables companies to make progress quantifiable and measurable, since business goals can be aligned with a max-/minimization of a certain function which has as parameter a certain set of data in a specified interval.
You can also use dashboards for a real-time health report of the deployed system.
I hope that I could help you with your current programming journey.
If you liked this article and want to read more articles in this context, don’t forget to subscribe :)