TORDU.JARDIN
· 3 min · carnet

Sous le capot : l'architecture en couches de Granit

J'ai découpé Granit en couches DDD pour réutiliser le même cœur métier dans le runner, le cloud et la CLI, sans réécrire trois fois la même logique de monitoring.

Projet rattaché Granit Golem Sur Azure, le prix d'un health-check explose : de quelques centimes à plusieurs euros pièce. Aucun outil self-hosted ne coche mes cases, alors je l'écris moi-même. Au passage, je lâche Claude Code à fond pour voir : le projet 'rikiki' vire en plateforme SaaS industrielle, et je passe un mois à éponger le bazar généré.
#backend #architecture

Vous avez déjà réécrit trois fois la même logique parce qu’elle vivait à trois endroits ? C’est précisément ce que ce découpage m’épargne. Sur la fiche projet, je l’ai survolé en une ligne ; ici, je creuse.

Des bounded contexts, pour de vrai

Le backend est découpé en bounded contexts (DDD) : un shared-kernel pour les types fondamentaux, des domaines monitoring et audit séparés en règles métier pures / use cases / infrastructure, et une couche api-server par-dessus.

Concrètement, je teste toute la logique métier sans démarrer PostgreSQL. Les tests s’exécutent en quelques secondes. Et je change de base sans toucher une ligne du domaine.

Toutes les flèches pointent vers le domaine. Le domaine, lui, n’importe aucune autre couche.

L'architecture en couches (DDD)

API & entrées

Ce qui parle au monde extérieur : HTTP (Axum) et ligne de commande.

  • api-server
  • api-core
  • api-types
  • cli

Application

Les use cases : orchestrer le domaine, sans porter de logique métier.

  • monitoring-application
  • audit-application

Domaine

cœur · zéro dépendance

Les règles métier pures. Aucune dépendance externe, testable sans démarrer PostgreSQL.

  • monitoring-domain
  • audit-domain
  • shared-kernel

Infrastructure

Les adapters concrets : PostgreSQL, clients HTTP, intégrations tierces.

  • monitoring-infrastructure
  • audit-infrastructure
  • discovery
  • clever-cloud-integration
Les dépendances pointent toutes vers l'intérieur. Le domaine, au centre, ne dépend de rien et se réutilise tel quel dans le runner, le cloud et la CLI.

Un cœur, plusieurs enveloppes

Comme le domaine ne dépend de rien, je le réutilise tel quel sous plusieurs habits. Le runner exécute les checks, l’appli cloud sert le front. Et chez l’utilisateur, le client CLI tourne en local. Tous embarquent le même domaine, sans copier-coller.

La règle métier ne vit qu’à un seul endroit.

Dans cette série