Software changes all the time. Requirements change, technology changes and patterns change. Using event-driven architectures can be great, as they allow you to be agile and adapt to change fast, but the road to implementing event-driven architecture does not happen overnight.

Implementing an event-driven architectures is a journey, a technical journey but also a journey for your organisation. There are many benefits to building event-driven architectures but the implementation itself is a continous effort (like all software we write!).

If you have legacy code and you want to move to an EDA application, you can use migration strategies to slowly migrate services into an EDA landscape (if it makes sense)! If you are looking to migrate I recommend using EventStorming to identify the behaviour of the system and start raising some basic events and consumers. Grow the producers and consumers over time and start to decouple your applications. Find the natural bounded context in your business domain and start to communicate with events.

If you want to build event-driven applications or already do, I believe it’s a journey and it will be a continuous journey, paired with ever changing business requirements EDA can be a great option to remain agile and adapt to change.

Start small, and grow your implementation over time.

Extra resources

• EventStorming Visual - Visual to help you learn about EventStorming.
• EDA Guide - Short guide to help you get started with event driven architectures.