When we kick of new projects or features, we often have this pressure to get things right up front. Design the solution and build it.

How can we build the right thing up front when knowledge is gained over time? Knowledge about practices, technology and more importantly the domain.

So, can we defer decisions we need to make using event-driven architectures?

I came across an interesting term called The project paradox. The idea is we tend to make the most important decisions up front when we built new features/architectures when this is the point of the least amount of knowledge. I believe this creates risks of building architectures that may not be fit for purpose, coupled and could slow us down.

So, what options do we have? We can use evolutionary architectures (e.g. EDA) to help us defer decisions, create components of the system that can be built/replaced when we have more knowledge about the domain.

Project Paradox

• The idea of the project paradox is we make the biggest decisions when we have the least amount of knowledge.
• The graph represents decisions vs knowledge over time. The section on the left is known as the Project Paradox.
• The project paradox creates risk of developing solutions that ultimately can slow us down. Systems that may be coupled by design. But how can we avoid this? We can look at how event-driven architectures can help here.

Defer decisions with event-driven architecture

• If there is possible risk of making the biggest decisions up front without the required knowledge, can we defer the decisions to later on?
• Using event-driven architectures we can create evolutionary architectures. These allow us to build components over time. In theory these components/services can be replaced as we understand the domain more, we have more options for refactors over time with these loosely coupled systems.

Evolutionary architectures

• With evolutionary architectures we can design systems that can change over time. We can change parts of the system when we gain more knowledge.
• We can use workshops like Event Storming to gain knowledge of the system and use methods from domain-driven design to help us develop a shared understanding between people.
• Be careful, evolutionary architectures can increase complexity as things become loosely coupled. Highly recommend understanding the importance of governance in EDA to help you.
• You can build evolutionary architectures over time, if you are coming from a legacy system, or want to get started. You can do this piece by piece.

Resources

• The project paradox - A nice blog post to dive into the project paradox with some more details, if you are interested.
• Building evolutionary architectures – Great book here from Rebecca Parsons, Neal Ford and Patrick Kua if you want to dive deeper into the subject and learn more.
• Learning Domain-Driven Design – Another great book here from Vlad Khononov. Domain-driven design and EDA go hand in hand. If you want to learn more, read this book.
• Event Storming – If you want to increase your knowledge in your domain and work with others within your org to do this, then take a look at Event Storming. This gives you a great way to get a shared understanding and help you on your EDA journey.
• Document your EDA – As you build your EDA you will come across issues around governance and documentation. This visual can help you learn more.