Screaming Architecture : Votre code doit crier son métier (pas son framework)

Imaginez : vous ouvrez un nouveau projet. Vous parcourez l'arborescence et vous tombez sur ceci :

src/
├── controllers/
├── services/
├── repositories/
├── dto/
└── entities/

Que fait cette application ? Impossible de le dire au premier coup d'œil. Est-ce un site e-commerce ? Un logiciel de gestion d'hôpitaux ? Un outil de trading ?

Rien ne "crie" le métier. On ne voit que de la technique. C'est précisément ce silence que la Screaming Architecture vient briser.

C'est quoi la Screaming Architecture ?

Popularisé par Robert C. Martin (Uncle Bob), ce concept est un pilier de la Clean Architecture. Son principe est radical mais salvateur :

L'architecture de votre logiciel doit crier son intention métier, et non les outils techniques qu'elle utilise.

Si vous construisez un système de réservation de vols, l'arborescence devrait afficher Booking, Flights et Payments dès le premier regard, et non Spring, Express ou TypeORM.

Le piège de l'organisation par "Couches Techniques"

La majorité des projets sont organisés par type de fichier (MVC classique). Si cette approche semble rassurante au début, elle devient un obstacle à mesure que le projet grandit :

Logique métier éparpillée : Pour modifier une seule fonctionnalité, vous devez sauter entre 5 dossiers différents.
Onboarding laborieux : Un nouveau développeur met des semaines à comprendre les règles métier cachées derrière la technique.
Couplage invisible : Les services finissent par tous s'appeler entre eux, créant un "plat de spaghettis" technique difficile à tester.

L'alternative : Structurer par Capacité Métier

Au lieu de ranger par "ce que c'est" (un controller), on range par "ce que ça fait" (passer une commande).

Mise en pratique : Exemple Concret

Prenons une application e-commerce. Comparons l'approche classique et la Screaming Architecture.

1. Avant (Organisation technique)

Tout est mélangé. Le fichier order.service.ts fait probablement 2000 lignes et gère tout, de la validation au stock. src/controllers/, src/services/, src/models/...

2. Après (Screaming Architecture)

L'intention est immédiate et modulaire :

src/
├── orders/ (Module métier)
│   ├── create-order.usecase.ts  <-- On voit l'action précise
│   ├── cancel-order.usecase.ts
│   ├── order.entity.ts          <-- La logique pure (Domaine)
│   └── order.repository.ts      <-- Interface de stockage
├── payments/
│   ├── process-payment.usecase.ts
│   └── refund-payment.usecase.ts
└── shipping/
    └── track-shipment.usecase.ts

Le gain est instantané : Même un non-développeur pourrait comprendre ce que fait l'application simplement en lisant les noms des dossiers.

Pourquoi devriez-vous l'adopter ?

✅ Une maintenance facilitée

Besoin de modifier le calcul de la TVA ? Vous savez exactement dans quel module aller. Le risque d'effet de bord sur le module de livraison est quasi nul.

✅ Un code qui se documente tout seul

Les Use Cases (cas d'utilisation) deviennent la documentation vivante de votre projet. Chaque fichier représente une règle métier concrète.

✅ Indépendance technologique

Le métier est au centre. Le framework (NestJS, Fastify, Spring) n'est qu'un détail d'implémentation. Vous pourriez changer de base de données sans toucher à votre logique de commande.

Comparatif : Quelle architecture choisir ?

Lisibilité métier

Architecture Classique : 🔴 Faible
Screaming Architecture : 🟢 Excellente

Rapidité au démarrage

Architecture Classique : 🟢 Très rapide
Screaming Architecture : 🟡 Modérée

Évolutivité (Scalabilité)

Architecture Classique : 🟡 Difficile
Screaming Architecture : 🟢 Très élevée

Niveau de l'équipe

Architecture Classique : Débutant
Screaming Architecture : Intermédiaire / Senior

Attention aux pièges (Les limites)

Tout n'est pas rose. La Screaming Architecture demande une réelle discipline :

Sur-ingénierie : Ne l'utilisez pas pour un simple blog ou un petit projet CRUD. C'est un marteau-piqueur pour enfoncer une punaise.
Discipline d'équipe : Si chacun commence à importer des composants de n'importe quel module sans règles de visibilité, vous perdrez tous les bénéfices.
Courbe d'apprentissage : Il faut accepter de "penser métier" avant de "penser code".

Conclusion : Ne restez pas dans le silence

La Screaming Architecture n'est pas une simple mode. C'est un investissement contre la dette technique structurelle.

En structurant votre code par le "Pourquoi" plutôt que par le "Comment", vous créez un logiciel qui survit au temps et aux changements de mode technologique.

Si votre arborescence ne raconte pas l'histoire de votre produit, elle finira par devenir un fardeau.