In this article, I am going to talk about why you should use Domain-Driven Design (DDD) in your practice. Does it really make sense to use Domain-Driven Design in your practice? This is the most fundamental, the most important question when you start thinking about applying Domain-Driven Design.
Well, let's get started.
The first fundamental problem is the two-language problem.
We have the language of business and software development. Business people work in a problem space. They try to learn more about the business, gather more information about it, and pass this information on to software developers.
Software developers, on the other hand, try to understand the business, ask more relevant questions about it, and translate the business language into software development.
Business people speak in a completely different language, but you have a completely different language in your code. So we have two languages. We are working in one company, but we are speaking two different languages. This is the most fundamental problem of classical software development.
When you use Domain-Driven Design, your business language becomes the language of software developers, and you don't need any translation. You have zero translation—completely zero translation. You're speaking the same language. We have ubiquitous language in Domain-Driven Design, which helps us speak in a single language. You have business terms, and these terms will be mapped exactly as-is to your software development. You don’t need to think about how to rename a class or how to name a method. What type of signature should it have etc?
This is a big problem because you are translating the business language. But Domain-Driven Design helps you not to translate, to have zero translation, and to use the same language.
Why is using the same language important?
Because the business helps software developers write really good code. On the other hand, developers help the business understand the domain because we are using the same language. We are helping each other.We, as developers, help the business. The business helps developers.
Another benefit is understanding the code. Even business people with limited technical knowledge can easily understand your code and easily identify where to make changes. As a software developer, it won’t take you a long time to add features or make changes to your code because you already know where to make the updates.
Understanding the code is really important—even for new engineers.
Let’s say in our company, we hire a new software developer. I don’t need to explain everything related to the code or the business or provide a lot of documentation, because our code is our documentation.
If you understand our code, you already understand our documentation. You understand our business. Because business is code. Design is code. Code is design.
Domain-driven design also helps us centralize business knowledge.
The business helps developers write good code. Developers ask a lot of detailed questions about the business. And the business also learns more about the business—because business people don't know everything either.
Join the conversation! Your thoughts help the community grow.