Bounded Context

• A central pattern in domain-driven design
• A contextual boundary as part of your domain.
• Has it’s own set of concepts and it’s own Ubiquouts Language.
• Provides a way to isolate and encapsulate parts of your system
• Great pattern to define boundaries for event-driven architectures
• Common patterns are to use events to communicate between boundaries.

Defining events / models

• Each boundary has its own language, use this language to define events and schemas within your boundary.
• You may have internal and external events within a boundary. External events may be used to communicate with other boundaries.
• Models may differ from boundaries, it’s important to understand different context mapping patterns you can use to transform events/messages before consuming them.
• Consuming an event directly into your boundary could couple you to the model of another boundary, think about that before you do it.

Communicate with events

• Event architectures allow us to define producers and consumers, theses producers and consumers can live across boundaries in your system, and event-driven architectures give us a great ability to communicate between these systems.
• If you follow domain-driven design practices with clear boundaries, you will have decoupled areas of your system, event architectures are a great way to keep decoupled, these go hand in hand.

Separation of concerns

• A big benefit of event-driven architectures is they allow us to be decoupled. This means changes to consumers have limited impact on other consumers/producers.
• If you have clear boundaries in your system and use event-driven architectures to help you can start to form a clear separation of concerns for your organisation and tech teams, allowing to scale solutions and teams faster.

Extra Resources

• Good and hard parts of EDA - Understand the good and hard parts of EDA, defining clear boundaries is just part of the whole picture, it’s important to explore more.
• What is Ubiquitous Language? - Visual here to help you understand what Ubiquitous Language is, and why it’s important.
• Transforming data between boundaries - When you consume events/messages between boundaries you may not want to take it as it is (raw), do you want to translate the data into your own domain? The answer, probably yes.
• Internal and external events - Firing events within your boundary, firing events outside? Integration? What does it all mean?