When triggered events in your event-driven architecture, you have to be mindful of what goes into your events, and the balance between raising events with too much or little information in them. Without careful consideration you can also expose too much domain/implementation details in your events, which might lead to some interesting side effects.

Exposing implementation details

• When using events to communicate between boundaries it’s easy to expose too much implementation or domain information. In the example above you can see the “type” exposed, this type is known by the order domain but downstream consumers have no clue.

• Within your own domains you will have your own domain models that tend to make to your own ubiquitous language. These models may or may not be understood by external consumers, think before you expose them.

• If consumers conform to your events with too much domain information, this domain information can bleed into other domains, and if not careful can create coupling between models.

• One way that can help is understanding bounded context mappings. Think about how you consume events, or agree contracts of events.

Embrace ubiquitous language

• Ubiquitous language is a set of vocabulary shared by a domain/product team. Language can change depending on what team or domain you talk too.

• As language changes (domain models), there is a mental mapping you may have to do between objects. We do this all the time when we communicate with other systems or teams within organisations.

• When consuming events, you may be consuming a model from another team, another language. You may want to consume this as it is or map it into your own language your code and team can understand, one way to do this is to use anti-corruption layers before consuming events.

• As organisations grow, I believe there is no getting away from teams having their own language, so embrace that and decide a strategy on how you are going to communicate between domains and teams using events.

Domain events vs integration events

• Your domain (microservice) may contain many parts, you may be using messaging or events within this domain to communicate. The events/messages are private events, they don’t tend to be used by other systems, but you and your team. These have a very different relationship vs events that are consumed by other teams (integration events).

• Within your domain (or service) when you raise internal events, you have more control of the contract/breaking changes. You might be OK to put domain information or implementation details in these events, you control them and your team may be the only consumers, so they should understand the domain and information in the events, better than external consumers.

• When you use events to integrate with other domains/consumers, you need to consider your event design and the long-lived contract you may have. Exposing domain information into other domains may not be great, and you may want to consider things like a public language (open host service) that could help.

Extra Resources

• Event-driven architecture with domain driven design - There is a great overlap between event-driven architecture and domain driven design. This visual I designed can help you understand them and why it’s important to know them.
• What is ubiquitous language - In this visual I created, we look and understand ubiquitous language in more detail with extra resources.
• Bounded context mapping - I like bounded context mappings, this allows us to think about patterns we use when we consume events. Should we take them as they are or map them? Or maybe agree on an open standard? Dive deeper.
• Open source bounded context mapping diagrams - Great Open Source resources here to dive deeper into context mappings, although not directly aimed at event driven architecture, they are still great and important to understand, you can map this learning into EDA.
• Event design and event first development - In 2022 I did a talk to help folks understand event design and event first development. I believe it’s important to get your design right when building event-driven architectures, this talk can help you dive deeper and understand why.