The Domain Driven Design, or just DDD, was created by Eric Evans and consists of the alignment of business and code construction, that way, the code generated must be the exact reflection of the business. For instance, if your business determines that all clients invoice must be paid until the deadline, that scenario should be the same in code design, like probably a Client class, an Invoice class with a deadline attribute, and a service class with a pay() method.
This is a very important characteristic of DDD because that way all people involved in this scenario can clearly communicate with each other. This process is called as Ubiquitous Language and it provides some good reasons to do it, like:
- The code reflects business and business refects code.
- Increase the code reuse, once that a specific domain can be used in different parts of an application.
- Loose coupling: a well-done model can operate independently in some cases since it represents a specific business piece.
- It is technology independent: a ubiquitous language it’s not concerned about technological choices, but in how business and technical areas will understand each other. In other words, it is concerned with how business logic will be interpreted and reflected in the code.
It is easy to find developers that don’t like that business stuff and prefer to code like a freaking machine. But in DDD this doesn’t work. Why? This answer is very simple: programmers are an important piece of this puzzle and they are called as hands-on modelers. Like I said before, all the team must be involved in the process. All the parts must be aligned!!!!!!! It doesn’t matter if the business and the architectural team are tightly aligned and the hands-on team doesn’t care about it. The result will be something that doesn’t represent a model and consequently doesn’t represent a domain!