Twenty years ago, Pat Helland identified three key patterns in autonomous computing: fiefdoms, collaborations, and emissaries. While fiefdoms have been explored via SOA and microservices and collaborations through workflows and sagas, less has been said about emissaries. Yet emissaries answer an essential question—how do you use a service? At its simplest level, the emissary is an SDK or UI, but this lens of external consumption misses the other value of the emissary within your architecture and not outside it.

From DDD, we learn about the bounded context as the boundary of ubiquitous language. However, our language bleeds out of our context into others without attention to context mapping. Eric Evans points out that microservices may not be single bounded contexts, separating out the ideas of their Internal Context from their Interchange Context.

In this talk, we look at the Emissary as an example of how we can implement an Interchange Context that reduces the bleed of language across contexts.

As specific examples, we will look at:
- Using Reference Data via ECST to build a forward cache and prevent the need for an HTTP GET between services, and how we can use the emissary pattern to avoid bleeding our domain details along with that reference data.
- The problem of ACID transactions that span service boundaries and how an emissary can allow you to run another service's code to prevent needing to distribute within that transaction.