Avoiding the big ball of mud in event-driven architectures By David Boyne

Avoiding the big ball of mud in event-driven architectures By David Boyne

Avoiding the big ball of mud in event-driven architectures

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

Want to work together?

If you're interested in collaborating, I offer consulting, training, and workshops. I can support you throughout your event-driven architecture journey, from design to implementation. Feel free to reach out to discuss how we can work together, or explore my services on EventCatalog.

Download EDA Visuals

Join over 13,000 others learning EDA and download all the EDA visuals directly to your computer. This document updates everytime a new visual is added so make sure you come back to get the latest.

Download now →
Diagrams and thoughts by @boyney123 to help you learn.