Architecture

Concevoir des systèmes qui restent simples à faire évoluer avec le produit.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. « 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.

  8. 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.

  9. 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.

  10. 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.