When building event-driven architecture your architecture will evolve, you will add more producers/consumers as time goes on. Without any design consideration you can easily end up with a “big ball of mud”.

“Big ball of mud” refers to an architecture that lacks structure, models within services become unclear, and it’s hard to iterate as there is no clean boundaries within the system. When you have a free for all with consumers / producers it can become easy to fall into this type of architecture over time.

To remain agile, resilient and have an architecture that remains loosely coupled, avoiding a big ball of mud can help.

Big ball of mud

• Architectures grow to the point they have unclear boundaries.

• Models are unclear within the architecture, hard to understand and change.

• Architecture can turn into a spaghetti code mess.

• With event-driven architecture it can become quite easy to fall into this type of architecture.

Create explicit domains and boundaries

• Event-driven architecture and domain-driven design (DDD) work very well together. With DDD practices we can identify our boundaries, core and subdomains within our architecture.

• A great way to do this with event-driven architectures is to explore Event Storming or Event Modeling and a tool to help you identify your logical boundaries.

• You want to work with domain experts to identify these boundaries and start to communicate a common language used.

• Having these boundaries makes it easier to manage and gain an understand of your architecture.

Understand private / public information

• When you have your boundaries there will be information / services / events that you may want to keep private within this domain.

• Private events tend to be events you use to communicate between services within a boundary. The contract of these events are different to events that are “public”. It’s less risky to put implementation details within these events, as the services within the boundary may understand the details (better than other services outside).

• Public information or events is information you want to share with other boundaries. These contracts are important, and it’s important not to expose too much (or if any) implementation details within your boundary. These event contracts are important, and some up front design of these events can help.

Define a language and use context mappings

• Each boundary will have its own common language (ubiquitous language), embrace that and understand that, things become easier once you identify this.

• When communicating with events (or APIS etc) it’s important to understand context mapping options you have. Do you want to consume as it is and be bound by the contract (Conformist), do you want to transform the message into something you can understand (anti-corruption layer), do you want to agree on a public language (open-host service), do you want to work even closer together (consumer-supplier relationship). Depending on what you want depends on what context mapping option you may explore.

• Consuming an event as it is, you are conforming to that contract. This is the default behaviour, you may or may not want to do this, but it’s worth noting and thinking about.

Extra Resources

• Event-driven architecture with domain driven design - I visual I created to help you understand why EDA and DDD work so well together, and extra resources to help you dive deeper.

• What is Event Storming? - Another visual to help you understand Event Storming with extra resources. A great tool to help you identify domains within your systems.

• Internal vs External events - Visual here to help you understand internal and external events.

• What are bounded contexts? - Here I dive into bounded context to help you understand what they are.

• Messages with bounded context - Dive deeper into context mappings with events.

• Learning Domain Driven Design - Some notes in this visual were taken from the book “Learning Domain Driven Design” by Vladik Khononov.

• Domain-driven design distilled - A nice book by Vaughn Vernon that gives a great overview of domain-driven design. This visual was inspired by notes in that book.

• Domain Driven Design and Event-Driven Architecture Podcast - Vaughn Vernon gives a podcast that dives into EDA and DDD. If you want to dive deeper worth a listen.