Domain Driven Design

What ?

Domain-driven design (DDD) is an approach to software development for complex needs by connecting the implementation to an evolving model. The premise of domain-driven design is the following:

  • placing the project’s primary focus on the core domain and domain logic;
  • basing complex designs on a model of the domain;
  • initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems

The term was coined by Eric Evans in his book of the same title.

DDD blue book

Why ?

DDD encompasses a common language, techniques, and patterns as well as an architecture. The focus is put on the business and on modeling the problems that are trying to be solved.

With DDD, the developers get techniques that will help to minimize complexity and that will help drive collaboration with the rest of the team. The idea is to use the requirements and to map out the business processes into the model by using the same language that is used by the business itself.

  • Business Necessities Are Oriented :
    With domain driven design, everyone ends up using the same language and terms and the team is sharing a model. Developers communicate better with the business team and the work is more efficient when it comes to establishing solutions for the models that reflect how the business operates, instead of how the software operates.

  • A Common Set of Terms and Definitions Used by the Entire Team :
    Teams find communication much easier during the development cycle because, from the beginning, they focus on establishing the ubiquitous language that is common to both parties (development and business experts). The language is linked to the domain model of the project and technical aspects are referred to through simple terms that all understand.

  • Better Code :
    With DDD you end up with more readable code and less duplication.

  • Get a Good Software Architecture :
    All the teams are able to understand where certain integrations are important and why. This means you know you’re getting a good software architecture.

  • Stay Focused on the Solution :
    The fact that there are clean boundaries around pure models enables the developers to put their efforts into what matters the most, it enables them to focus on the solution.

Bounded context

How ?

Resources

Share this challenge