It’s inevitable that software evolves over time, requirements change, domains within businesses change.

At the start of a new project, it seems relatively simple for us to get a holistic view of the whole system/architecture.

As time goes on services evolve, business requirements change and (hopefully) organisations grow and scale. This means the cognitive load to understand the architecture and business domains increases and things can become harder to scale, work with and adapt.

Event-driven architectures can provide the ability to respond to changes, design architectures that support evolutionary changes within organisations and provide teams the ability to scale whilst reducing the cognitive load required to understand the architecture and business domains within it.

Evolutionary domains

• Software changes all the time. Businesses get new requirements, requirements change, new services are created or services are depercated. The landscape is constantly evolving.

• Teams at the start of the project may be able to fully understand the “whole picture”, the business domain and every single service they build, but over time as teams scale it can be challenging to rapidly scale with everybody needing to know everything.

• With event-driven architectures messages/events can be used to communicate between boundaries, this enables teams/domains within organizations to focus on a particular business problem (or collection of problems) and use messages/events to communicate with other boundaries/systems.

• Having teams focused within domains allows them to specialise within that domain.

Split domains, communicate with events

• Many businesses want to scale, and want their software architecture to enable agility.

• Splitting teams into domains/services is a common pattern organization use to able growth.

• Teams within the domains are specialists of that domain. They understand the needs/requirements of the business within that domain.

• Teams can use messages/events to communicate between boundaries. This allows them to design a contract that can be used and notify others.

• This pattern reduces the cognitive load that teams need when developing solutions within their domain, but it is still required for someone to have the bigger picture.

• One common mistake when building event-driven architectures is losing the “bigger picture”. For example, standards of events, documentation of the system, how to handle retries, idempotency etc.

• Having engineers/architects that understand the whole domain is super important, and can help guide engineers within these teams.

Extra Resources

• Large-Scale Architecture: The Unreasonable Effectiveness of Simplicity - This visual was inspired by Randy Shoup. This is a great talk about large-scale architectures, talking about async, event-driven and patterns to help. This reminded me of the importance of reducing cognitive load when scaling teams.
• The fundamentals of event-driven architecture - Another visual I made about the fundamentals of EDA. Reducing cognitive load is just part of the benefits you can get when using EDA, this visuals dives deeper into some of the fundamentals I believe we need to understand before building EDA applications. Hopefully it can help you.
• Publishing events without consumers - Think of events as an interface into your domain, you don’t have to only publish events when consumers ask for them, think about your domain and publish events even without consumers.
• Bounded context with event-driven architecture - Directly from domain driven design, the bounded context. Super important to understand if you want to create domains/boundaries around your services and uses events/messages to communicate.
• Use event storming to help identify your domains - If you are trying to find your domains or want to dive deeper with your teams, check out this visual to help. An overview of Event Storming and resources to help you.