When you build event-driven applications you can use events to communicate between services and boundaries. Many people use EventStorming to highlight events and business domains.

Within a bounded context you can have many different services and communicate between these services using events, sometimes these are referred to as “private”, “internal” or “domain” events (depending on what you read…). These events belong within the bounded context, they can be exposed to implementation details and raise events assuming that downstream consumers understand the domain language used in the boundary and implementation details, they are “private” and not meant for “public” consumption.

Using events to communicate between between bounded contexts (remember this can be within in your organization or outside your organization) can be referred to as “public” or “integration” events. Event contracts are important here, and ideally you do not want to expose private or implementation details of your domain in these. Consider a public language to communicate between systems (Defining a ubiquitous Language can help here).

Private/Internal Events

• Can expose internal implementation details
• Use a language that the domain understands, external domains may not understand this
• Contract is important, but depending on how “close” the services are within boundary, could be relaxed?

Public/Integration Events

• Should not really expose implementation details of the domain
• Events use a language that is shared between the business or boundaries, no assumptions made
• Contract is extremely important. Outside your domain you have less knowledge of who is consuming your events, don’t break them.

Extra resources

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