Repositories, ports et anti-corruption

Prérequis : cours 3.2 et 2.2 (Adapter) ; requêtes générées.

Pourquoi

Le domaine doit ignorer SQL, HTTP et fichiers : sinon chaque changement technique casse le métier. Repository + ports = le domaine parle à des interfaces, l'infra les implémente.

Concepts

• Repository : collection feinte d'agrégats (orders.save(o), orders.ofId(id)). Le domaine ne voit ni SQL ni ORM — l'implémentation vit en infra.
• Ports & Adapters (hexagonal) : le domaine au centre, des ports (interfaces) vers l'extérieur, des adapters qui branchent le réel (PostgresAdapter, SmtpNotifier). Tester le domaine = brancher des fakes, sans base ni réseau.
• Couche anti-corruption (ACL) : traducteur entre un système externe et ton modèle (cf. Adapter 2.2, version DDD). Le vocabulaire externe ne pénètre JAMAIS le domaine.

Exemple : le domaine testable

// domaine : OrderService dépend du port, pas de Postgres
function shipOrder(order, { orders, clock }) {
  order.ship(clock.now());
  orders.save(order);
}
// test : orders = fake en mémoire, clock = figée. 5 ms, zéro infra.

Cas réel

Migration Postgres → autre base : domaine et tests inchangés, seul l'adapter réécrit. Sans ports : 200 requêtes SQL dispersées dans le métier, migration = réécriture.

Pièges

• Repository qui fuit (retourne des query builders / rows SQL) : l'abstraction est percée, tout le bénéfice perdu.
• Ports pour tout, même le stable : YAGNI — on isole ce qui change (infra externe), pas les utilitaires internes.
• ACL oubliée « pour aller vite » : le vocabulaire externe colonise le domaine en 3 mois.

À retenir

Domaine = ports, infra = adapters, externals = ACL ; fakes pour tester vite.