What is Domain-Driven Design?
6 Interview Questions and Answers About Domain-Driven Design
It was a while ago. The workday had come to an end and afterwards, I would attend an interview with a potential new client. During the interview, it felt like the interviewer shared the same ideas about software development and their product looked promising. Everything went rather well — until — unfortunately, the interviewer asked: “ What is Domain Driven Design?”
Imagine you sitting there. What would you have said? It’s hard to come up with a great definition of such a broad concept like Domain-Driven Design, isn’t it? Where do you even begin?
It is difficult to answer that question with conviction. If this was not the case, everyone would apply Domain-Driven Design flawlessly. And then in 2003, Eric Evans would not have needed 560 pages to write a book about it. What the interviewer expected to hear, was enthusiasm and eagerness to learn. Instead, he experienced an awkward moment of silence.
He didn’t see that the interviewee was trying to form a definition in his head of all the notions he had on this subject. The interviewer could not see this and actually, we can’t blame him for that. It is the interviewee’s job to think out loud. Tip: Think out loud and if you don’t know something, at least say you’d like to learn it.
In this blogpost let us walk through six important concepts. If you run into the same question, tell your interviewer that it’s a very broad concept. And also tell him/her that you have a notion of some of the important concepts from Domain-Driven Design. Discuss some. If you don’t want to start by reading a book of 560 pages, you can start here. Afterwards, you will understand what Domain-Driven Design is all about.
1. What is a “Domain”?
The subject area on which the application that is being developed applies is called the Domain. When developing an application it is always good to know the context in which it applies. Sometimes there are multiple domains in which an organization can be active. For example, a company can be active in sales, transport and repairs, all at the same time.
An organisation can organise itself differently for sub-domains. If you are developing an application for sales, it is best to look at it from “sales”. The language of the developed application will be aligned with the business and the application will make more sense overall (E. Evans, 2003).
2. What is a “Bounded context”?
In Domain-Driven Development “Bounded Context” is an important concept. It gives more information on how to deal with large domain models and a large organization. To deal with a large model you can divide the model into different zones which we call a “Bounded Context”.
An organization can be split into a sales department and a support department, each operating within its context. By working in a bounded or limited context the work becomes easier and better organized (M. Fowler, 2014).
3. What does “Ubiquitous Language” mean?
In basic terms, a ubiquitous language is a language shared by the development team and the domain experts. Because they have to work closely together to create a short feedback loop, this makes perfect sense.
The language has to be used not only in the domain model, but also in the code of the application. If the development team and the business team wouldn’t work together, the chance would increase they’d develop their language. This could introduce a language barrier between them (DDD, 2019).
Let’s summarize some key characteristics of the ubiquitous language:
- must be expressed in the Domain Model.
- keeps “technical” developer language out of the Domain Model, which would not be understood by the domain experts.
- mitigates contradictions and inaccuracies to be introduced to the Domain Model by domain experts.
- evolves as the application grows.
4. What is an “Anti Corruption Layer”?
To prevent two domains to pollute each other, you have to create a boundary between them. Each domain has its ubiquitous language and its domain model.
An anti-corruption layer translates between the two domain models. The layer can be uni or bi-directional and is often implemented by well-known patterns (e.g. adapter, facade, translator). We have to keep in mind that creating an anti-corruption layer can be time-consuming. It should only be used if you want to protect your domain from outer influences (A Shirin, 2018).
5. What is the difference between an “Entity” and a “Value Object”?
It’s important to understand the difference between Entities and Value Objects to model the real world in an application. I will list the main differences between them here (V Khorikov, 2016):
- Identity: Value Objects have no identity, while an Entity does. Value Objects that have the same values are inherently equal. Entities exist on their own.
- Life cycle: Value Objects do not live on their own and belong to some Entity. They can be destroyed and created with ease. Entities live on and have history.
6. What is an “Aggregate”?
An aggregate is a domain-driven design pattern. It’s a cluster of domain objects (e.g. entity, value object), treated as one single unit. A car is a good example. It consists of wheels, lights and an engine. They conceptually belong together.
Every aggregate has an aggregate root. In our example, this might be the chassis number. It ensures the integrity of the aggregate as a whole. Every aggregate denotes a transactional boundary (M. Fowler).
Conclusion
The answers to these questions should give you a good idea of what exactly is meant by Domain-Driven Design. Don’t consider this as a complete guide.
So much has been written on this subject that you can read several books about it.
If you have must-reads on this subject, share them. Respond to this story and be a hero. 560 pages by Eric Evans later I feel like I’ve only started my DDD journey.
Interested in personal training or coaching? Mail me at info@kwal-it.be or visit our site for our other services.
