Domain-Driven Design.

Affronter la complexité au cœur du logiciel en modélisant explicitement le domaine métier, et en gardant ce modèle — ainsi que le code qui l'exprime — en étroit alignement avec le langage utilisé par les personnes qui comprennent le domaine.

À mesure qu'un système grandit, les règles métier tendent à se disperser entre les contrôleurs, les services et les requêtes de base de données. Le code s'éloigne de la façon dont le métier parle réellement de son travail, de sorte que chaque conversation nécessite une traduction et que chaque changement risque de casser une règle dont personne ne se souvenait.

Les conceptions centrées sur les données aggravent cela : les modèles deviennent des sacs anémiques de getters et de setters, les invariants ne vivent nulle part en particulier, et le système se transforme lentement en une « grosse boule de boue » que seules quelques personnes osent toucher.

Le Domain-Driven Design attaque le problème sur deux niveaux.

La conception stratégique divise un grand domaine en contextes délimités — des frontières explicites à l'intérieur desquelles un modèle et son langage sont cohérents — et cartographie les relations entre eux. Chaque contexte est libre de modéliser le même concept différemment là où le métier le voit véritablement différemment.

La conception tactique construit un modèle riche au sein d'un contexte à partir d'un petit ensemble de blocs de construction, et insiste sur un langage ubiquitaire : les mêmes termes apparaissent dans les conversations, dans le modèle et dans le code.

Les blocs de construction tactiques :

• Entités — des objets définis par une identité qui persiste dans le temps (un Customer, un Order).
• Objets-valeur — des objets immuables définis par leurs attributs (un Money, une Address).
• Agrégats — des grappes d'entités et d'objets-valeur avec une unique racine d'agrégat qui protège les invariants de la grappe et constitue le seul point d'entrée pour les changements.
• Dépôts (repositories) — des interfaces de type collection qui chargent et persistent des agrégats entiers, masquant les détails de stockage.
• Services de domaine — des opérations sans état qui n'appartiennent pas naturellement à une seule entité.
• Événements de domaine — des enregistrements de quelque chose de significatif qui s'est produit dans le domaine.

Les blocs stratégiques — contexte délimité et carte de contexte — organisent ces modèles entre équipes et sous-systèmes.

• Utilisez-le quand la complexité essentielle réside dans les règles métier, pas dans la technologie — logistique, finance, assurance, planification.
• Utilisez-le quand plusieurs équipes doivent s'accorder sur une compréhension partagée et évolutive d'un domaine.
• Évitez-le pour de simples applications CRUD ou de saisie de données, où le coût de modélisation vous apporte peu.

1. Discutez avec les experts du domaine et distillez le langage ubiquitaire ; consignez les termes et leur signification.
2. Identifiez le cœur de domaine — la partie qui procure l'avantage concurrentiel — et concentrez-y l'effort de modélisation.
3. Découpez le domaine en contextes délimités et dessinez une carte de contexte de leurs relations.
4. Au sein d'un contexte, modélisez des agrégats de sorte que chacun applique ses propres invariants en une seule transaction.
5. Chargez et sauvegardez les agrégats via des dépôts (repositories) ; publiez des événements de domaine pour ce qui intéresse les autres contextes.
6. Affinez continuellement — le modèle n'est jamais « terminé », il évolue à mesure que la compréhension s'approfondit.