Skip to content

Domain Driven Design: “What” not “How”

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.

Learn more about Software Architecture & Design.
Join thousands of developers getting weekly updates to increase your understanding of software architecture and design concepts.


Common LanguageMany 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

Boundaries 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.  

Leave a Reply

Your email address will not be published. Required fields are marked *