Moteur applicatif¶

Statut¶

Document normatif d’architecture.

À quoi sert cette couche ?¶

Le moteur applicatif (Application Engine) coordonne les cas d’usage de CMonChoix.

Un cas d’usage est une action complète demandée à la plateforme, par exemple :

résoudre une identité produit ;
lancer une reconstruction ciblée ;
produire un rapport de validation ;
appliquer une réparation métier explicitement autorisée.

Le moteur applicatif organise les étapes nécessaires, mais il ne possède ni la vérité métier ni les détails techniques de stockage ou de transport.

Exemple concret¶

Supposons qu’une commande demande de reconstruire une projection produit.

La responsabilité doit rester séparée :

CLI / HTTP / Worker
        ↓
      App
        ↓
Application Engine
        ↓
Domain + Contracts
        ↓
Write Service / Infrastructure

La CLI ne doit pas contenir toute la logique. Le moteur applicatif coordonne le cas d’usage. Le Domain prend les décisions métier. Les Contracts définissent les frontières. L’Infrastructure réalise les détails techniques.

Ce que le moteur applicatif fait¶

Il peut :

recevoir une entrée stable provenant d’une App ;
coordonner plusieurs objets du Domain ;
appeler un Factory ou un service métier ;
utiliser des Contracts stables ;
agréger plusieurs résultats ;
retourner un résultat explicite au point d’entrée.

Ce qu’il ne doit jamais faire¶

Il ne doit jamais :

définir un invariant métier ;
décider lui-même de la vérité produit ;
exécuter directement du SQL ;
appeler directement WordPress ;
lancer Docker ;
lire des fichiers marchands ;
parser un format propre à un marchand ;
appeler directement une API partenaire ;
dépendre d’une classe d’Infrastructure concrète ;
contenir une commande CLI ou un contrôleur HTTP ;
posséder le scheduling ou les workers du Runtime.

Différence entre Application et Domain¶

Le Domain répond à la question :

Quelle décision métier est correcte ?

L’Application répond plutôt à :

Quelles étapes faut-il coordonner pour accomplir ce cas d’usage ?

Exemple :

Application : « je dois résoudre puis persister cette identité »
Domain      : « voici la décision d’identité correcte »
Write Service : « voici comment appliquer l’écriture autorisée »

Différence entre Application et Runtime¶

Le Runtime décide quand et dans quel contexte une action est exécutée : worker, cron, CLI, HTTP, reprise, verrou, batch.

L’Application décrit le cas d’usage lui-même.

Ainsi, le même cas d’usage peut être déclenché par une CLI aujourd’hui et par un worker demain sans déplacer sa logique métier.

Différence entre Application et Apps¶

Les Apps sont les points d’entrée exécutables : CLI, HTTP, worker, cron, etc.

Une App doit rester mince :

lire les paramètres ;
les valider ;
appeler le bon cas d’usage ;
afficher ou retourner le résultat.

Si une commande CLI contient plusieurs centaines de lignes de règles métier, la frontière est probablement mauvaise.

Relations avec les Contracts¶

Les Contracts permettent au moteur applicatif de demander une capacité sans dépendre de son implémentation concrète.

Par exemple, Application peut dire :

« j’ai besoin d’un stockage capable de persister ce résultat »

sans connaître la table SQL, $wpdb ou le moteur de base de données réellement utilisé.

Comment diagnostiquer un problème¶

Si un cas d’usage échoue, vérifier dans cet ordre :

Entrée — les paramètres transmis par la CLI, l’HTTP ou le worker sont-ils corrects ?
Application — le cas d’usage appelle-t-il les bonnes capacités ?
Domain — la décision métier produite est-elle correcte ?
Contract — l’implémentation respecte-t-elle l’interface attendue ?
Infrastructure — le problème vient-il de SQL, du réseau, d’un fichier ou d’un service externe ?

Cette méthode évite de corriger une erreur technique dans le Domain ou une règle métier dans la CLI.

Signaux d’alerte¶

Une modification mérite une revue attentive si elle ajoute dans Application :

une requête SQL ;
un appel WordPress ;
une lecture directe de fichier marchand ;
une règle propre à Samsung, Acer ou une autre source ;
une dépendance vers un renderer Frontend ;
une gestion de cron ou de queue ;
une vérité métier qui devrait appartenir au Domain.

Règle de transmission¶

Pour une personne qui reprend le projet, retiens cette phrase :

Application coordonne, Domain décide, Infrastructure exécute techniquement, Runtime déclenche.

Si tu sais identifier laquelle de ces quatre responsabilités est concernée, tu éviteras une grande partie des mauvaises corrections architecturales.

Critères de conformité¶

Un cas d’usage applicatif est sain lorsqu’il :

possède un objectif clair ;
reçoit des entrées explicites ;
retourne un résultat explicite ;
coordonne sans créer de vérité métier ;
ne dépend pas directement de SQL, WordPress ou d’un Adapter ;
utilise des Contracts pour ses dépendances techniques ;
reste réutilisable depuis plusieurs points d’entrée.