https://quentinpigne.github.io/architecture/domain-driven-design/index.htmlLe Domain Driven Design est une approche de conception logicielle formulée par Eric Evans en 2003 dans Domain-Driven Design: Tackling Complexity in the Heart of Software — le « livre bleu ». Son objet n’est ni une architecture, ni une bibliothèque de patrons : c’est une réponse à une observation simple. Dans un logiciel d’entreprise qui dure, la complexité qui coûte le plus cher n’est pas technique, elle est métier. Et le seul levier dont on dispose contre elle est un modèle — une représentation partagée du domaine, comprise autant par les développeurs que par les gens du métier, et inscrite dans le code.Hugofr-FRhttps://quentinpigne.github.io/architecture/domain-driven-design/langage-omnipresent/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://quentinpigne.github.io/architecture/domain-driven-design/langage-omnipresent/index.htmlVoletStratégique Le point de départ de DDD, et celui qu’on croit toujours avoir déjà réglé. Dans un projet ordinaire, trois vocabulaires coexistent. Celui du métier — des gens qui parlent de « dossier », de « bordereau », de « régularisation ». Celui des développeurs — OrderDTO, processItem, statusFlag. Celui de la base — des tables héritées de 2011, des colonnes nommées flg_actif. Chaque conversation traverse deux traductions, et chaque traduction perd de l’information.https://quentinpigne.github.io/architecture/domain-driven-design/sous-domaines/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://quentinpigne.github.io/architecture/domain-driven-design/sous-domaines/index.htmlVoletStratégique La page qui détermine où l’effort de modélisation est rentable — et où il est du gaspillage. Problème et solution La distinction la plus clarifiante de tout DDD, et celle qu’on saute le plus souvent : Nature Verbe Domaine et sous-domaines L’espace du problème — ce que fait l’entreprise On les découvre Contextes délimités L’espace de la solution — comment on décide de le modéliser On les conçoit Le domaine, c’est l’activité de l’entreprise : la vente de billets, le transport de colis, la gestion de sinistres. Il existe indépendamment de tout logiciel, et il ne se négocie pas. Les sous-domaines sont ses parties distinctes : la tarification, l’expédition, la comptabilité, l’authentification des utilisateurs. Ils ne sont pas non plus un choix — ils sont là, on les constate.https://quentinpigne.github.io/architecture/domain-driven-design/contextes-delimites/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://quentinpigne.github.io/architecture/domain-driven-design/contextes-delimites/index.htmlVoletStratégique Le concept central de DDD. Si une seule notion doit être retenue de tout ce corpus, c’est celle-ci. Un contexte délimité est une frontière explicite à l’intérieur de laquelle un modèle s’applique et chaque terme a exactement un sens. En dehors, le modèle ne prétend rien. Les mêmes mots peuvent y désigner autre chose, et c’est très bien. Le problème qu’il résout Prenez le mot « client » dans une entreprise de taille moyenne, et posez la question à trois services.https://quentinpigne.github.io/architecture/domain-driven-design/cartographie-de-contextes/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://quentinpigne.github.io/architecture/domain-driven-design/cartographie-de-contextes/index.htmlVoletStratégique Les frontières ne suffisent pas : reste à savoir qui dépend de qui, et à quelles conditions. Une carte de contextes représente les contextes délimités d’un système et la nature de leurs relations. Sa particularité, et ce qui la rend inhabituelle pour un artefact technique, est qu’elle décrit deux choses à la fois : un flux de données et un rapport de force organisationnel. Les deux comptent, et le second est souvent le plus déterminant.https://quentinpigne.github.io/architecture/domain-driven-design/entites-objets-valeur/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://quentinpigne.github.io/architecture/domain-driven-design/entites-objets-valeur/index.htmlVoletTactique Les deux briques de base du modèle — et le choix entre les deux est plus déterminant qu’il n’y paraît. Warning Rappel de dosage avant d’entrer dans le détail : les patrons tactiques ne sont rentables que dans le cœur de métier. Sur un sous-domaine de support, un objet valeur par champ est une dépense sans retour. Voir Sous-domaines. Le critère : identité ou valeur Une seule question sépare les deux notions.https://quentinpigne.github.io/architecture/domain-driven-design/agregats/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://quentinpigne.github.io/architecture/domain-driven-design/agregats/index.htmlVoletTactique La notion la plus difficile de DDD, et celle qui rapporte le plus. C’est aussi celle qui est le plus souvent mal comprise — presque toujours de la même façon. La question à laquelle un agrégat répond Ce n’est pas « comment regrouper mes classes ». C’est : Quel ensemble de données doit être cohérent à chaque instant, et donc modifié dans une seule transaction ?https://quentinpigne.github.io/architecture/domain-driven-design/services-depots-fabriques/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://quentinpigne.github.io/architecture/domain-driven-design/services-depots-fabriques/index.htmlVoletTactique Les trois patrons de soutien : où loger la logique qui n’appartient à aucune entité, comment récupérer un agrégat, et comment en fabriquer un. Service de domaine Un service de domaine porte une logique qui appartient bel et bien au domaine, mais à aucune entité ni objet valeur en particulier. Deux cas de figure, et deux seulement :https://quentinpigne.github.io/architecture/domain-driven-design/evenements-de-domaine/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://quentinpigne.github.io/architecture/domain-driven-design/evenements-de-domaine/index.htmlVoletTactique Le mécanisme qui rend possible la quatrième règle des agrégats — et, plus largement, le découplage entre contextes. Un événement de domaine est un fait métier significatif qui s’est produit. Trois caractéristiques, toutes conséquentes : Il est au passé. ReservationConfirmee, PaiementRefuse, ColisExpedie. Un nom au présent ou à l’impératif — ConfirmerReservation — désigne une commande, c’est-à-dire une intention qui peut échouer. Un événement, lui, est déjà arrivé : on ne le refuse pas, on en tient compte.https://quentinpigne.github.io/architecture/domain-driven-design/event-storming/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://quentinpigne.github.io/architecture/domain-driven-design/event-storming/index.htmlVoletPratique L’atelier d’Alberto Brandolini. De tout DDD, c’est la pratique au meilleur rapport valeur/effort, et la seule applicable dès la semaine prochaine sans rien changer au code. Le principe : réunir dans une même pièce les gens qui savent et les gens qui construisent, et modéliser le métier comme une suite d’événements sur un mur, avec des post-its. Pas de diagramme, pas d’outil, pas de notation à apprendre.https://quentinpigne.github.io/architecture/domain-driven-design/mise-en-oeuvre/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://quentinpigne.github.io/architecture/domain-driven-design/mise-en-oeuvre/index.htmlVoletPratique L’architecture qui va avec, les pièges qui font échouer les adoptions, le chemin dans un code existant — et les cas où il faut s’abstenir. L’architecture qui va avec DDD ne prescrit aucune architecture. Il impose une seule contrainte, mais elle est forte : le domaine ne doit dépendre de rien. Ni ORM, ni framework, ni client HTTP, ni annotation.