Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
Many years have past since Eric Evans release the blue book: Domain Driven Design. A lot has changed over the years but I find the core ideas still hold very true.
In some ways, I think some of the concepts outlined are even more prevalent now than they have ever been.
Ubiquitous Language
The Ubiquitous Language is a shared language developed by the team. The team is everyone working on the project: developers, domain experts, QA, BA. Everyone on the team. The ubiquitous language isn’t developed by the domain expert(s) alone. If you have more than one domain expert, they may struggle with language between each other to define concepts. Everyone apart of the team is building, growing and refining the language. Language is critical to not only verbal communication but how it’s represented in the software we are writing. It represents the concepts and terms specific to the core business domain we are trying to model. All the expressions, nouns and verbs are what the team is formally defining with an ubiquitous language.Bounded Context
One of my favorite concepts is of the bounded context. Bounded context should be autonomous.
Meaning, a bounded context should be independent and self governing.
It defines a set of business capabilities within the domain and represents a conceptual boundary.
One way of determining where the boundaries lie is with the ubiquitous language.
If a term or phrase has a different meaning in another context, you may have discovered a boundary and therefor another bounded context.