Using Domain Driven Design
The first tips and tricks for implementing domain driven design.
This is part two of a summary series I am doing on a podcast I co-host, you can find it at: www.iterationpodcast.com
Part one: What is Domain Driven Design?
Make sure your domain design is practical
Imagine a software developer encounters this massive, extremely complex domain model, with associations to many different representations of objects. It resembles the cliché image of newspaper clippings on the wall, strings connecting them everywhere. An impressively detailed, intricate domain model to be used by the software developers.
Often times developers end up ignoring this kind of a massive model. They see the verbs and the nouns, but only use it as a loose guideline and make their own model during the process. This massive, complex model just becomes a huge waste of time.
When you don’t have a clear model, you end up with procedural, spaghetti code all over the map, because there is nothing to hold the logic together.
Make sure you actually use it
What is the point of the domain model if you don’t use it? Tight coupling of the model and the implementation is essential to solve the main problem the software is aiming to tackle. Making your domain model too large and complicated makes it impossible to use in practice.
Like Evans Says in Domain Driven Design:
“If the design or some central part of it does not map to the domain model, that model is of little value and correctness of the software is suspect.”
A Good Domain Model
An astrolabe is a good metaphor for a domain model that holds up in practice. It is a mechanical representation of the night sky, and sailors can twist it to know how the stars are aligned or how they’ll be aligned in time. It is an interesting way of looking at software: it is a loose representation that is not static. It moves the way the stars do, there’s logic and movement in the model.
Binding the model to implementation
One of the pitfalls to avoid is going off into the tangent of analyzing the model, but not translating it well into the software you write. It is crucial using the language in the model all the way to the code, on the lowest level possible.
In domain driven design, the bones of a design can be revealed to the user more than other design approaches. The more you clearly articulate the shared language, the more you can share that all the way up to the user interface.
For example, think of a main hamburger navigation: when you click and the main items come up, those could be some of your nouns from the shared language. And if they cannot be used there, then you are choosing pretty bad nouns.
Refine your code by refining your language
You need constant communication between domain experts and software developers so that you can bind the model to the way you code.
Think about the telephone game as a metaphor for this: first person says a secret to the next person, and the last person gets a message that is completely different. But when you’re playing the game, if you say “can you repeat that?” when you don’t understand and keep that iteration, you will have a message that is very close to the originating one.
Going back to software development, just like the telephone game, it is crucial to be constantly communicating, iterating back and forth to establish a ubiquitous language and the model. Communication enables both parties to be on the same side, the software developers and the domain experts, instead of each side having their own interpretations and ending up with a solution that doesn’t solve the initial problem. The workflow must allow for a system where you first define a model and establish a ubiquitous language and communicate each other’s needs.
What is driving the development?
Let’s say you get a request and see a ticket from a user. It is easy to fulfill the request, to solve the ticket. It is very difficult to get to the roof of this request, asking the questions below it.
The worst kind of development is when you have a higher up wanting some X, Y, Z features and you just implement them. The conversation about development needs to be led by the customer in an intuitive way, through customer driven data. That way, you can get a refined build out of iteration, getting better faster and faster.
Challenges with user generated content
When building something like a survey building tool, with heavily user customizable content, coming up with a shared language becomes more difficult.
In the case of a survey building tool, there are actually more than one domains in play. There is the low level question of why you’re making a survey, and there is implementation of the survey building tool itself. There are also multiple domain experts in play in this situation, the survey creating domain experts and the domain experts on the purpose of the survey. It is important to have a good common language to allow for arbitrary data collection.
This is part two of a summary series I am doing on a podcast I co-host, you can find it at: www.iterationpodcast.com
Iteration — A weekly podcast about development and design through the lens of amazing books, chapter-by-chapter. We do our best to be code-agnostic but we talk a lot about Rails, JavaScript, React, React Native, design, business and startups.
P.S. This article was written with help from Senem Soy based on content from our podcast episode. Thanks Senem!
