Domain-Driven Design

Domain-Driven Design (DDD) is a paradigm proposed by Eric Evans in his book of the same title. It offers a consistent approach to modeling complex business processes in the application. It doesn’t provide specific advice at the code level. Instead, it offers a set of terms and techniques that model business processes and translate them into code.

DDD is useful when we’re building enterprise software, and it’s more valuable the more complex our business processes are. But, if we’re doing something small like a command-line snake game, DDD might be overkill.

Domain and model

At the core of DDD (and in its name) is Domain, the area of knowledge or business processes our application tries to improve. And, at the core of our application is Model, an in-code representation of Domain. It has the same name as the Model in MVC, and that’s for a good reason—we’re talking about the same thing.

Let’s return to our example with an application that books concert seats. If we detach ourselves from UIs, servers, and databases, we start thinking about what should happen in general. Concerts have a certain capacity, and people can book seats for that concert, reducing capacity. Once the concert capacity is met, we can’t sell tickets anymore. This is our ...