One of the guidelines around building ubiquitous languages is that there should be one per bounded context.

In a domain that has more than one bounded context, and therefore more than one ubiquitous language, how should you deal with vocabulary that is different in each context, but related to each other with respect to the entire domain?

For example, objects in our domain contain a property that dictates the object's identity, but constraints within each bounded context restrict ubiquity in both implementations, and these could not easily be circumvented...

// Implemented in one bounded context
object Customer {
  id: guid

// Implemented in another bounded context
object Customer implements Identity {
    identity: Identifier

Note that id and identity in each bounded context refer to the same thing, but their names and data types differ.

How do I achieve ubiquity across these implementations when referring to this from the perspective of the domain as a whole, and is there a suitable method for translating between the two?

  • Id’s are a bad example as they usually don’t belong in the domain at all. When two people from sales talk to each other they’re not referring to a customer by id. To translate between bounded contexts, DDD uses anti-corruption layers.
    – Rik D
    Apr 30, 2019 at 19:05
  • 1
    It may surprise you that how to go about this depends not only on the domain (as it will be informed by how and where the business translates between the concepts in real life), but also on other considerations, like how the teams working on each bounded context are organized, how well they can coordinate, and even on what's the power dynamic between them. If you can get your hands on Eric Evans' book, most of Ch. 14 is about relating bounded context. May 1, 2019 at 13:58


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Browse other questions tagged or ask your own question.