Domain-Driven Design

Domain-Driven Design, also known as DDD, is an approach to software development that separates the whole big project unity into smaller and simpler projects, each representing a distinct domain — “domain” being the particular field of knowledge for which the software is being built. By extension, it also tends to separate the general development team into smaller teams, each working on the respective domain for which it is responsible. To better understand the concept of Domain-Driven Design, first we need to ask why we should apply it instead of any different software development approach.

Suppose DDD is not being applied, and the project in which we are working can in fact be divided into more than one subset of domains. In this case, we are seeing the system that we are creating as a big picture instead of seeing it in terms of its more specific and focused parts; thus making the whole software development process a lot more complex and difficult, since we are not only ignoring the specializations that could have been made in order to facilitate the implementation, but, fundamentally, we are throwing away the so useful principle of “divide and conquer”.

For example, if we were to build an online shopping system, and our client also wanted to keep track of some reports such as best sale item, best sale month and so on, we could divide the general project into two: one for dealing with these reports, and another one to deal with the operations of purchasing and selling themselves. Not only that, but we could also — if we wanted to — create a third division: a subset of the online shopping system that deals only with login, logout and registering new users.

It is easy to see that this sort of separation creates the necessity for some kind of integration. Not coincidentally, Domain-Driven Design recommends the application of continuous integration in the development process. That aspect of DDD is fundamental in maintaining coherence between the multiple modules that are being implemented and that represent each distinct domain.

Besides its many strengths, DDD is not necessarily to be used every time and in every circumstance. Like all other software development approaches, the need for its use depends enormously on the situation that is being dealt with. Its value and potential, however, should not be diminished — as it was demonstrated in this very article.