Skip to main content
Welcome. This site supports keyboard navigation and screen readers. Press ? at any time for keyboard shortcuts. Press [ to focus the sidebar, ] to focus the content. High-contrast themes are available via the toolbar.
serard@dev00:~/cv

Model-Driven en TypeScript : un mini-shop, quatre métamodèles, un cadre méta-méta

La thèse en trois phrases

L'écosystème TypeScript a des templates (plop, hygen, nx generators), il a des compilateurs source-à-source, il a depuis peu un moteur de génération multi-stage à la Roslyn avec @frenchexdev/ts-codegen-pipeline. Il n'a pas encore de cadre éditorial pour : décrire un domaine métier comme un M1, le projeter à travers plusieurs métamodèles composés (DDD × CQRS × VerticalSlice × Telemetry), et émettre un graphe de packages npm dont les frontières correspondent aux frontières du métier — tout cela en laissant explicitement des trous (ImplementationSlot) que l'humain ou l'IA remplit sous garde de quality gates. Cette série propose ce cadre, le décrit en public, et le démontre sur un mini-shop marchand B2B + B2C multi-tenant baptisé OpenStore.

Le cadrage tient en une image : on monte d'un cran (M3), on décrit comment décrire des métamodèles et leurs relations, et on génère le code TypeScript des transformations qui projettent un M1-OpenStore vers six packages npm — @openstore/domain, /slices, /telemetry, /front (SSR + SPA hydratée), /back (admin multi-tenant), /api. Chaque ligne de code émise porte sa trace vers le Requirement qui l'a justifiée. Aucune logique métier n'est devinée ; elle est contractualisée par des AcceptanceCriterion que les implémentations doivent passer.

Cette série est design in public : le cadre M3 n'existe pas encore comme package distinct du monorepo. Les extraits TypeScript fournis dans le dossier assets/ compilent (tsc --noEmit) mais sont des squelettes — ils définissent le vocabulaire, pas un runtime. La force du format est de pouvoir corriger le cadre avant qu'il existe, sur un cas réaliste, à voix haute.

Pourquoi maintenant

Trois raisons, par poids stratégique croissant.

La première est que la fondation est prête. @frenchexdev/ts-codegen-pipeline fournit déjà l'engine multi-stage (VirtFS, fixpoint, banner SHA256, strictly additive). @frenchexdev/requirements-lib fournit déjà le DSL Requirements/Features/AcceptanceCriteria. Cette série ne réinvente ni l'un ni l'autre — elle propose la couche éditoriale qui les compose : un cadre pour décrire le M2 d'un domaine métier complet, pas juste un microDSL isolé.

La deuxième est qu'aucun corpus français accessible ne raconte cette chaîne complète — modèle métier → métamodèles composés → transformer → packages npm émis — sur un domaine réaliste. Les introductions au MDE existantes (académiques, héritées d'ATL/QVT) restent abstraites ou couplées à Eclipse/Java. Cette série prend un mini-shop B2B + B2C multi-tenant comme fil rouge et le tient sur dix chapitres, sans changer d'exemple en cours de route.

La troisième est positionnelle. La série ts-source-generator a posé l'engine. La série microdsls-and-kernel a posé le M2 kernel. Cette série pose le M3 — le metamodel des métamodèles — qui rendra possible une future variante TypeScript de Ide.Dsl. Quand Ide.Dsl-TS arrivera, son article 1 commencera par : « On suppose le cadre M3 décrit dans model-driven-typescript. »

Comment lire la série

Dix articles, quatre arcs implicites.

Arc I — Vocabulaire et état de l'art (2 articles)

  1. M0, M1, M2, M3 : un vocabulaire pour parler de transformations — la pile OMG, les emprunts (rule, helper, guard, trace, megamodel), pourquoi le M3 mérite un article.
  2. Comment on en est arrivé là : ATL, QVT, Acceleo, Epsilon, MPS, Roslyn, Langium — un demi-siècle d'outils, ce qu'on en garde, où le cadre proposé se positionne.

Arc II — Le M1 et les quatre métamodèles (5 articles)

  1. OpenStore : un mini-shop B2B + B2C multi-tenant comme fil rouge — surface fonctionnelle, B2C BuyNow versus B2B RequestQuote, multi-tenant, front + back office.
  2. Métamodèle DDD (excerpts) — @AggregateRoot, @Entity, @ValueObject, @DomainService, @DomainEvent, @Invariant, @Repository.
  3. Métamodèle CQRS (excerpts) — @Command, @Query, @CommandHandler, @QueryHandler, @EventStore, @Projection, @ReadModel, @Saga.
  4. Métamodèle VerticalSlice (excerpts) — @Slice, @Endpoint, @Pipeline, @Behaviour, @Authorization, @Validation.
  5. Métamodèle Telemetry (excerpts) — @Span, @Metric, @Logged, @Sampled, @TraceContext.

Arc III — Composition, transformer, M2C (2 articles)

  1. Composer DDD × CQRS × VerticalSlice × Telemetry — pas un union ensembliste, un produit relationnel. Résolution du conflit @DomainEvent, cross-relations explicites.
  2. Le transformer composite : M1-OpenStore → squelettes de packages npm — VirtFS + fixpoint, six packages émis, ImplementationSlot aux frontières du métier, traces inscrites dans le code.

Arc IV — Le cadre méta-méta (1 article)

  1. Le cadre méta-méta : générer le transformer, garantir SOLID/DRY/Req-Feat-AC — M3 explicite, TransformerGenerator.generateFromComposition(...), garanties par construction, position face à ts-codegen-pipeline, requirements-lib et Langium.

Ce que cette série n'est pas

Ce n'est pas un nouveau package du monorepo. C'est un cadre éditorial — prose + extraits TypeScript type-check-only — qui peut être implémenté plus tard, après que ses contours auront été discutés ici. Ce n'est pas non plus un toy example : OpenStore couvre B2C, B2B, multi-tenant, front office SEO + SPA, back office multi-utilisateurs, sur les quatre métamodèles à la fois. La dilution de la complexité est la pédagogie, pas un échauffement qu'on jetterait au chapitre 5.

Ce n'est pas une réécriture de ATL en TypeScript. Le cadre n'est pas bidirectionnel (contrairement à QVT-Relations), il ne propose pas d'éditeur LSP (contrairement à Langium), il ne génère pas un binaire par tenant. Ce qu'il fait, en revanche, il le fait sur un domaine réel et avec des traces qui remontent jusqu'au requirement — c'est ce qu'on attendait depuis quinze ans des outils MDE et qu'on n'avait jamais en pratique.

⬇ Download