What is Domain Driven Design?
This is part one of a summary series I am doing on a podcast I co-host, you can find it at: www.iterationpodcast.com
The Domain: For a 5 year old
It’s the things someone needs to know to do their job. So a police officer needs to know certain things about how to drive a car, shoot a gun all the laws that all everyone needs to follow.
Example:
- Uber’s domain is Transportation. A taxi cab driver would have a good idea of the types of domain models and common concepts. Things like, Drivers, riders, fares, destinations, routes and more. All related to the domain of transportation.
Why does this matter?
As software developers, we are trying to build tools to help people do their jobs or accomplish specific tasks. Without a good understanding of the domain you can’t build great software.
Domain experts are not usually aware of how complex their mental processes are. They fill in knowledge with what they consider to be common sense and software can’t do this.— Eric Evans in Domain Driven Design
The model is a set of concepts built in the heads of people in a project with terms of relationships that reflect domain insight .Ultimately, the goal is to be able to be on the same page of concepts in the domain.
Extracting the nouns
In the Uber example above we called out some “nouns” that could be used within this domain. Thinks like:
- Driver
- Rider
- Destination
- Route
- Ride
- Receipt
Every project has it’s “nouns” — nearly every app or website with a login has a concept of a “user” of some kind. But all apps have their own sets of nouns. Early in a project being intentional about finding and sharing these nouns is extremely helpful.
A Shared Language
The model is the backbone of language used by all team members and as they use the shared language they begin to explain things more precisely inconsistently. — Eric Evans in Domain Driven Design
The model is a set of concepts built in the heads of people in a project with terms of relationships that reflect domain insight. So, a strong shared model can help programers and and non-technical collaborators work together more seamlessly. It’s easy in software to just be talking around each-other or use unclear communication.
That said — whenever you talk about the thing that you’re building whether it’s an app or a Web site try to use the nouns you’ve extracted from your project. In slack and in e-mails and on the white board. It’s got to be the same words that are there that are in your codebase. The more you force this common language the more it gets refined. It’s really that these nouns pervade every piece of communication. It feels really unnatural at first. Language can be awkward but as you refine the conversation and use them in practice you are actually refining your software design at a higher level.
Full Immersion
Full immersion language learning is a learning format that makes students only use the language they are trying to learn throughout the class. From day one the teacher doesn’t use any language from the students native language.
I took Spanish this way in College. It was awful.
The thing is is it forces you to get to some level of proficiency that you’re able to communicate with your other classmates. This is a perfect language for establishing a common language. It forces everyone to actually understand what the other is saying.
It shouldn’t be technical
A good domain design isn’t technical jargon. it’s plain english terms that everyone working in the domain can understand. Should be simple english nouns and verbs. Whenever possible developers should use these same nouns and verbs internally in the codebase.
The purpose of software to solve a problem. Software is just a tool that helps us solve these problems. The level of complexity of the software should only exceed the complexity of the problem when absolutely necessary. Us developers can overcomplicate the domain by introducing language or framework specific terms and language.
