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.
“What”, not “How”
With the rise/hype of
microservices, the concept of a bounded context continues to hold true.
How do functional languages impact domain driven design? As I’m leaning F#, I’m not overly concerned about the “how”.
The important part modeling a domain for me is the
verbs, not the state. I do think that will translate well to a functional language.
Focusing on the
what not the
how is what makes Domain Driven Design still very important and applicable so many years later.