https://quentinpigne.github.io/tags/rust/index.htmlHugofr-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/solid/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://quentinpigne.github.io/architecture/solid/index.htmlSOLID est un acronyme rassemblant cinq principes de conception orientée objet popularisés par Robert C. Martin à la fin des années 1990. Ils ne portent pas sur la correction du code — un programme peut violer les cinq et fonctionner parfaitement — mais sur son coût de modification. Le problème qu’ils traitent est toujours le même : dans un logiciel qui vit, un changement ne reste jamais local. On touche une classe, et trois autres cessent de compiler ; on ajoute un cas, et il faut relire un switch de deux cents lignes. Les cinq principes sont autant d’angles d’attaque sur cette propagation, et ils convergent tous vers la même idée : maîtriser le sens des dépendances.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/design-patterns/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://quentinpigne.github.io/architecture/design-patterns/index.htmlEn 1994, quatre auteurs — Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides, restés dans l’histoire sous le nom de Gang of Four — publient Design Patterns: Elements of Reusable Object-Oriented Software et y catalogue vingt-trois solutions récurrentes à des problèmes de conception objet. Leur apport réel n’est pas d’avoir inventé ces solutions : la plupart existaient déjà dans les bases de code de l’époque. C’est de leur avoir donné un nom. Dire « ici, un Observer » transmet en deux mots une intention, une structure et ses conséquences connues — c’est un vocabulaire de conception, et c’est à ce titre qu’il reste utile trente ans plus tard.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/couplage-cohesion-connascence/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://quentinpigne.github.io/architecture/couplage-cohesion-connascence/index.htmlLes pages précédentes donnent des règles : une classe ne doit avoir qu’une seule raison de changer, une frontière se place là où le langage change, le domaine ne doit dépendre de rien. Toutes présupposent une capacité qu’aucune n’enseigne : savoir juger si une dépendance est acceptable. Le couplage et la cohésion sont la seule mesure réelle de cette question, et elles datent de 1974. Le problème est que « couplage » est un mot beaucoup trop grossier : dire « c’est couplé » ne dit ni à quel point, ni pourquoi, ni quoi faire. La connascence est l’instrument fin qui manque — elle gradue ce que le mot « couplage » aplatit en un seul jugement.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/n-tier-architecture/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://quentinpigne.github.io/architecture/n-tier-architecture/index.htmlL’architecture en couches organise le code en strates horizontales superposées, chacune ne s’adressant qu’à celle qui se trouve en dessous. Sa forme dominante, et de très loin, est le 3-tier : un contrôleur, un service, un dépôt. C’est l’architecture par défaut du développement d’entreprise. La plupart des applications l’adoptent sans décision explicite, parce que c’est la forme que proposent les frameworks et celle qu’on obtient en séparant naïvement « ce que voit l’utilisateur », « ce que fait le programme » et « ce qui est stocké ».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/hexagonal-clean-architecture/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://quentinpigne.github.io/architecture/hexagonal-clean-architecture/index.htmlTrois noms circulent pour à peu près la même idée. Ports et adaptateurs, proposé par Alistair Cockburn en 2005 — l’« hexagone » n’a jamais eu six côtés pour une raison particulière, il s’agissait seulement de ne pas dessiner un rectangle avec un haut et un bas. Onion architecture, formulée par Jeffrey Palermo en 2008. Clean architecture, popularisée par Robert C. Martin en 2012. Leurs différences réelles sont traitées en fin de page ; elles sont plus faibles qu’on ne le croit.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/monolithe-microservices/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://quentinpigne.github.io/architecture/monolithe-microservices/index.htmlC’est la première question qui dépasse le périmètre d’une application, et celle qui est le plus systématiquement mal posée. « Faut-il faire des microservices ? » n’a pas de réponse, parce que ce n’est pas une question d’architecture : c’est une question de topologie de déploiement. La décision de modélisation — où passent les frontières du métier — est un sujet distinct, traité par les contextes délimités. Cette page traite de ce qui vient après : quelles frontières déjà identifiées méritent de devenir des unités de déploiement séparées, et à quel prix.https://quentinpigne.github.io/architecture/cqrs-event-sourcing/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://quentinpigne.github.io/architecture/cqrs-event-sourcing/index.htmlCes deux notions sont presque toujours présentées ensemble, et c’est la première chose à défaire. Ce sont deux décisions indépendantes, aux profils de coût radicalement différents : CQRS est bon marché et souvent déjà à moitié fait sans qu’on l’ait nommé ; l’event sourcing est l’une des décisions les plus chères de tout le catalogue, et elle est rarement justifiée. Sans event sourcing Avec event sourcing Sans CQRS Le cas ordinaire, et souvent le bon Presque impraticable : plus aucune requête possible Avec CQRS Le cas utile, et de très loin le plus fréquent Réservé aux domaines dont l’historique est le produit La seule dépendance réelle va dans un sens que l’on énonce rarement : l’event sourcing impose CQRS, puisqu’un flux d’événements ne se requête pas. L’inverse est faux — CQRS n’a aucun besoin d’event sourcing, et c’est la combinaison qu’il faut viser par défaut.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.https://quentinpigne.github.io/architecture/resilience/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://quentinpigne.github.io/architecture/resilience/index.htmlLa page Monolithe, modulaire, microservices énumère ce que le réseau facture : un appel qui peut expirer alors que le travail a été fait, une disponibilité qui se multiplie le long d’une chaîne, des pannes partielles permanentes. Voici ce qu’on paie avec. Ces patrons forment le pendant du catalogue du GoF à l’échelle distribuée. Ils ont été catalogués par Michael Nygard dans Release It! (2007), sous le nom de stability patterns, et ils partent d’un renversement de perspective :https://quentinpigne.github.io/architecture/tests-architecture/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://quentinpigne.github.io/architecture/tests-architecture/index.htmlToutes les règles posées dans cette section ont un point commun : ce sont des intentions. « Le domaine ne dépend de rien », « une couche n’appelle que celle du dessous », « seule la façade du module est importable », « aucun ORM dans le domaine ». Rien, dans un dépôt ordinaire, ne les empêche d’être violées — et une règle d’architecture non vérifiée est violée en quelques semaines, sans mauvaise volonté de personne.