Recherche : [ddd] - Antichesse (o ^ω^ o)

What is Domain-Driven Design (DDD)

Merci à @Riduidel pour le lien.

Je copie-colle le résumé :

What is Domain-Driven Design (DDD)

A definition of DDD as a software design discipline

By @mathiasverraes
Published on 22 September 2021

Domain-Driven Design is a software design discipline centred on the principles that:

Software for a complex domain requires all designers (engineers, testers, analysts, …) to have a deep, shared understanding of the domain, guided by domain experts

That understanding is rooted in language: the domain language should be formalised into a Ubiquitous Language (shared, agreed upon, unambiguous)

The understanding is expressed in a model, shared between experts and designers, which express the problem space (as opposed to the solution space)

The model must not shy away from explicitly expressing the essential complexity of the domain

A complex domain can not be efficiently expressed as a single universal model and language, and must therefore be separated into Bounded Contexts (ie. an internally consistent language and model) by the system designers

The model and language should be in sync with our understanding of, and changes in the domain, through continuous refactoring towards deeper insight

As a mnemonic:

DDD is a design discipline where you

Grasp the domain

Agree on a language

Express it in shared models

Embrace complexity

Separate models in contexts

… and evolve them continuously

Notes
Domain-Driven Design presents an all-encompassing view on software design. It considers design from the micro-level of code and design patterns, to models and their language, to communication and relationships between models, to the large scale reasoning about systems of systems. On top of that, it aims to be pragmatic. You don’t apply DDD everywhere, you do it where it will have the most impact.

DDD is not prescriptive. It doesn’t have rules of how to do it, and is open to new interpretation. It doesn’t prescribe methods, or practices, and even the patterns in the book1 are meant to be illustrative rather than a final set. Many methods that people now consider core to DDD, such as EventStorming, didn’t exist when the book was written.

That makes DDD notoriously hard to define. This definition is specifically focused on DDD as a discipline, that is, design as something you do, activities with a set of guiding principles. I’ve been using and improving this definition in my workshops for probably 6 or 7 years now, so I hope that makes it hardened enough to be useful for both newcomers to DDD and seasoned practitioners. I hope that keep it up to date with new insights.