En couches, hexagonale : organiser le code

Prérequis : cours 3.3 (ports) ; architecture Nest, couches et patterns.

Pourquoi

« Où mettre ce code ? » — sans réponse partagée, chaque dev improvise et le projet devient un labyrinthe. Une architecture, c'est d'abord une convention de rangement qui survit aux auteurs.

Concepts

• En couches (layered) : présentation → applicatif → domaine → infra, dépendances vers l'intérieur uniquement. Simple, efficace, 80 % des apps n'ont besoin que de ça.
• Hexagonale (ports & adapters) : le domaine au centre ne dépend de rien ; tout le reste est un adapter branché sur un port (cf. 3.3). Plus stricte, plus testable — le surcoût se paie sur les apps qui durent.
• Règle d'or commune : le métier ne connaît jamais le framework (pas d'import Express/Nest dans le domaine) ni la base. Si retirer le framework casse le métier, l'archi a fuité.

Exemple : découpage NestJS propre

src/
  orders/            # module métier
    order.entity.ts  # domaine pur, zéro import Nest
    order.service.ts # cas d'usage, ports injectés
    order.controller.ts  # adapter HTTP (connaît Nest, pas l'inverse)
    order.repository.ts  # adapter Postgres

Cas réel

Domaine qui importe l'ORM partout (@Entity décoré dans les objets métier) : changer d'ORM = réécrire le métier. Séparation refaite (entités pures + mappers) : migration faite en 2 semaines au lieu d'un trimestre.

Pièges

• Hexagonal pour un CRUD de 3 tables : YAGNI — en couches suffit, l'hexagonal attendra la complexité réelle.
• Couches qui se contournent (« juste pour cette fois, le controller appelle le repo ») : une exception devient la norme en un mois. Linter la règle si besoin.
• Domaine anémique (objets vides + services qui font tout) : l'archi ne remplace pas la modélisation (chapitre 3).

À retenir

Convention partagée, dépendances vers l'intérieur, métier sans framework ni base.