Étude de cas · Produit personnel
Batchmeal
Une application de planification de repas en batch cooking, conçue comme un exercice d'artisanat logiciel exigeant : appliquer pour de vrai, sur un produit réel, le TDD outside-in, le Domain-Driven Design et la Clean Architecture.
- 5
- bounded contexts
- ≈ 580
- tests (back + front)
- 90 %
- mutation testing (PIT + Stryker)
- 10
- règles ArchUnit
- 15+
- outils MCP exposés
Pourquoi ce projet est ma meilleure carte de visite
Aucune vente pour l'instant, et ce n'est pas le sujet. Batchmeal est la démonstration tangible de mon niveau d'exigence : ce que vous voyez ici est exactement la rigueur que j'apporte à vos applications critiques.
Architecture hexagonale
Le domaine au centre, pur, sans aucun framework. Les entrées (HTTP, MCP) et les sorties (base de données, API externes) sont des adaptateurs branchés en périphérie. La règle de dépendance pointe toujours vers le métier, jamais l'inverse.
Un vrai domaine, pas du CRUD
Le calcul du besoin énergétique n'est pas un simple champ : formule de Mifflin-St Jeor, coefficients d'activité EFSA (PAL), ajustement par objectif (perte / maintien / prise), puis recalibration sur l'historique des pesées (28 jours). Modélisé en value objects et invariants, testé pour de vrai, isolé du framework.
Ce que ça démontre
Clean Architecture vérifiée par la machine
Dix règles ArchUnit imposent la règle de dépendance au build : domaine et couche applicative sans Spring, JPA ni Jackson, intégration entre contextes limitée à un « published language ». L'architecture ne peut pas dériver silencieusement.
Domain-Driven Design réel
Cinq contextes bornés (comptes, profils nutritionnels, catalogue d'aliments, batch cooking, journal) plus un shared kernel, chacun un module Maven, communiquant par événements de domaine publiés après commit.
≈ 580 tests, TDD outside-in
Cycle RED, GREEN, refactor : ~200 tests back-end et ~380 tests front-end. Mutation testing à 90 % (PIT côté Java, Stryker côté TypeScript), couverture domaine et cas d'usage (JaCoCo), aucun code défensif sans test qui échoue d'abord.
Livraison MCP-first
Chaque cas d'usage exposé à la fois en endpoint HTTP, outil MCP pour l'IA et widget HTML, une approche pensée pour l'ère des agents.
Livraison MCP-first, en détail
Il n'y a pas d'interface web au départ. Chaque cas d'usage est livré simultanément sous trois formes, avec un mapping strict :
- 1 cas d'usage
- 1 endpoint REST
- 1 outil MCP
- 1 widget HTML
Résultat : je pilote tout le produit depuis un client de chat (MCP Inspector, ChatGPT, Claude Desktop) avant même d'écrire la moindre ligne de React. Le domaine passe en premier, l'interface vient après — une approche pensée pour l'ère des agents.
Stack technique
- Java 25
- Spring Boot 4.1
- Spring AI 2 (MCP)
- PostgreSQL 18
- Flyway
- Vavr (Either)
- ArchUnit
- JUnit 5
- PIT
- Testcontainers
- Pact
- JaCoCo
- Spotless
- React 19
- TypeScript 6
- Redux Toolkit
- Vite 8
- Tailwind CSS 4
- Playwright
- Stryker
- Biome
- Maven multi-module
- pnpm monorepo
- Docker multi-stage
- GitHub Actions
Industrialisation et CI
Le projet est outillé comme une vraie application de production :
- intégration continue GitHub Actions : build et tests à chaque pull request ;
- commits conventionnels et releases automatisées (release-please) ;
- formatage et lint imposés (Spotless côté Java, Biome côté TypeScript) ;
- tests de mutation (PIT, Stryker) et tests de contrat (Pact) pour la fiabilité.