Architecture
Concevoir des systèmes qui restent simples à faire évoluer avec le produit.
Développer un programme : les questions que l'IA ne tranche pas
Sous-domaines, bounded contexts, archi, data, scale, sécurité, prod : les questions à se poser quand on développe un programme et que l'IA seule ne tranche pas.
Faites analyser vos bounded contexts par une IA
Relations, changements, langage, maintenance : des sous-agents IA qui analysent vos bounded contexts peuvent révéler des problèmes profonds de design.
Bounded contexts : pourquoi bien les designer ?
Bien designer ses bounded contexts protège le langage de vos modèles, simplifie l'organisation et, via la context map, guide vos choix techniques.
Subdomains et bounded contexts : le problème et la solution
En DDD, on confond souvent subdomains et bounded contexts. Les premiers existent dans le business, les seconds sont designés pour organiser le software.
L'outbox pattern : la cohérence en dehors de l'agrégat
Un agrégat garde la cohérence à l'intérieur d'une brique métier. Pour ce qui est dehors, comme l'email de facture, l'outbox pattern garantit qu'il part.
L'agrégat en DDD : une frontière de cohérence pour vos invariants
En DDD tactique, l'agrégat regroupe des objets liés derrière une racine unique, pour que vos invariants restent vrais, y compris au moment de la persistance.
Core, supporting, generic : les trois types de subdomains
Analyser le business domain révèle trois types de subdomains : core, supporting et generic. Les identifier, c'est savoir où mettre son temps et son effort.
Fatigué par le rythme de l'IA ? Revenez aux bases
Sorties, workflows, outils : avec l'IA, tous les devs découvrent la fatigue que les devs JS connaissent. Ma parade : rebosser les bases, stables et durables.
Le Result Pattern : distinguer bug et erreur métier
cancelOrder() peut échouer de plein de façons prévisibles. Le Result Pattern distingue l'erreur métier qu'on renvoie du bug qui part dans Sentry.
Architecture logicielle et craftsmanship à l'ère de l'IA
Transaction Script, DDD, Clean Architecture, CQRS, TDD, SOLID, Big Ball of Mud : bosser l'architecture logicielle n'a jamais été aussi utile ni accessible.
Effort de maintenance = Force × Distance × Volatilité
Vlad Khononov présente à DDD Europe une formule simple : il suffit de ramener une seule dimension à zéro pour que l'effort de maintenance s'effondre.
Un bon harnais IA permet d'utiliser des modèles moins chers
Sur une codebase aux règles d'import enfreintes, Opus corrige seul, Haiku s'y fait piéger, jusqu'à ce qu'une règle ESLint le corrige pour 4 à 5 fois moins cher.
La valeur d'un projet tech est dans les règles métier
Les règles métier, pas la technologie, concentrent 80 % de la valeur d'un projet tech. Pourtant la plupart des projets commencent par le code ou les interfaces.
Les ADR racontent à l'IA l'histoire que le code ne raconte pas
README, CLAUDE.md et AGENTS.md ne racontent que l'état actuel du code. Les ADR ajoutent l'histoire : pourquoi cette décision, quelles alternatives écartées.
La première semaine sans écrire une ligne de code
Sur un projet greenfield ou brownfield, ne pas toucher au clavier la première semaine : comprendre, challenger l'architecture, modéliser le métier.
La boy-scout rule : moderniser une codebase sans big bang
Mettre à jour les conventions d'une codebase sans big bang refacto : à chaque fichier touché, on applique les dernières règles décidées par l'équipe.
Majuscules-Driven Development : crier sur l'IA ne sert à rien
Crier en majuscules sur une IA pour qu'elle respecte une règle d'architecture ne sert à rien : un outil déterministe la vérifie à votre place.
Zéro ligne de code écrite à la main : mon expérience
J'ai relevé le défi d'écrire un programme sans taper une seule ligne moi-même, en poussant le harnais IA à son maximum, inspiré par une expérience d'OpenAI.
Pourquoi je demande un ADR avant chaque décision d'architecture
Un ADR tient sur une page : contexte, décision, conséquences. L'idée de Michael Nygard (2011) n'a pas pris une ride, et c'est un guide gratuit pour l'IA.
Un framework opinionated, c'est un harnais pour l'IA
AdonisJS est réputé très opinionated. Discussion avec Jonathan Serra (AI2H) sur pourquoi cette rigidité donne un harnais de plus à l'IA.
Multi-tenant : les quatre niveaux de séparation des données
Un SaaS qui gère des données sensibles doit séparer celles de chaque client. Quatre niveaux, du tenant_id à l’infra dédiée, et celui que je choisis souvent.
Un « Model », c'est quoi ? Deux choses qui n'ont rien à voir
« Model » désigne le Model d’un ORM comme le domain model du DDD. Les confondre fait croire qu’on a modélisé son métier alors qu’on a décrit ses tables.
Functional Core, Imperative Shell : la fin des mocks partout
Le talk Boundaries de Gary Bernhardt (2012) reste un des meilleurs conseils de testing : séparer décisions et actions, ne passer que des valeurs entre les deux.
Architecture saine, features mal faites : vous survivrez
Une architecture saine et des features mal faites, on survit. Une architecture bancale, tout devient un combat. Et c'est le plus compliqué du métier.
dependency-cruiser : un capteur computationnel pour vos agents IA
dependency-cruiser cartographie les imports et fait échouer la CI quand une frontière est violée. Un capteur pour l’IA, qui exige une architecture claire.
Vertical Slice Architecture : ranger le code par requête
Ajouter un champ touche six fichiers dans quatre dossiers ? La fonctionnalité n'est rangée nulle part. La VSA de Jimmy Bogard range le code par requête.
Combien de vos règles d’architecture cassent le build ?
Avec l’IA, une architecture standardisée devient un atout : chaque règle vérifiable par une machine est une contrainte, les autres ne sont que des intentions.
« A dépend de B » : de quoi parle-t-on exactement ?
Une dépendance peut être vue par le compilateur, par un test, ou par personne. Trois questions pour rester précis, entre développeurs comme face à une IA.
Une « couche » en architecture logicielle, c'est quoi ?
Abstraction, technique, flux d'appel, dépendances, déploiement : « couche » désigne cinq découpages différents, et votre programme les a sans doute tous.
Clean Architecture : la Dependency Rule, et rien d'autre
Ce que Robert C. Martin extrait en 2012 des architectures Hexagonale, Onion et consorts : une seule règle vérifiable dans le code, la Dependency Rule.
L'Onion Architecture : le code métier au centre
Jeffrey Palermo, 2008 : une règle de dépendance unique pour que le code métier ne subisse plus les changements de technologie.
Parnas et Cockburn : comment s'imbriquent leurs deux visions
Le Port/Adapter de Cockburn n'est qu'une application tactique de la stratégie de Parnas : chaque duo Port/Adapter est un module qui cache un choix techno.
Architecture Hexagonale : le pattern Ports & Adapters de Cockburn
Alistair Cockburn, 2005 : penser un programme comme un intérieur métier et un extérieur branché via des ports et des adapters, plutôt qu'en couches.
Parnas, 1972 : selon quel critère découper en modules ?
En 1972, David Parnas propose de découper un programme non pas selon un flowchart, mais pour cacher dans chaque module ce qui est difficile ou va changer.
Scaler un MVP vibecodé : quand les opérations lourdes explosent
Une opération lourde traitée en mémoire par l'IA tient en prototype, puis explose quand les utilisateurs affluent. Sans queues ni observabilité, bon courage.
Le meilleur harnais IA : une codebase à l'architecture rigoureuse
DDD, TDD, hexagonale ou conventions maison : peu importe. Une codebase rigoureuse est le meilleur harnais pour qu'une IA suive votre façon de faire.
Le bon code paraît simple, le mauvais paraît intelligent
Écrire un code intelligent qui paraît simple est l'une des choses les plus dures en développement : derrière, un découpage propre et des choix invisibles.
Écrire du code est facile, construire un système ne l'est pas
Avec l'IA, écrire du code est devenu aussi facile qu'apprendre à écrire. Construire un système complexe, cohérent et durable reste un travail de chef-d'œuvre.
Les cinq formes de couplage, de la plus acceptable à la pire
External, common, control, stamp, content : cinq formes de couplage classées de la plus acceptable à la pire, et comment limiter chacune dans une codebase.
Le pire sur une codebase, c'est le couplage
Des modules un peu pourris mais bien découpés, ça ira. Des modules optimisés mais couplés dans tous les sens, c'est un enfer à maintenir.
DDD + Clean Architecture : mon avis après 3 mois intensifs
Trois mois de DDD et Clean Architecture appliqués à la lettre sur une codebase en production : les pour, les contre, et pourquoi je ne m'en passerai plus.