Aller au contenu

Verticale Printer

Statut

TARGET — verticale projetée, non certifiée comme module Runtime actif.

Cette page décrit le contrat métier attendu pour une future verticale Printer. Elle ne prouve ni qu'un module Printer complet existe dans le Runtime, ni qu'il est chargé, ni qu'il participe aujourd'hui aux résolutions de production.

La présence d'une catégorie printer ou d'une feuille « Imprimantes » dans l'architecture publique de navigation ne constitue pas une preuve d'activation métier.

Rôle attendu

La verticale Printer doit encapsuler les règles propres aux imprimantes et éviter que leurs caractéristiques particulières ne contaminent le Domain Core générique.

Elle peut notamment contribuer à interpréter :

  • la marque et la famille de modèle ;
  • le type d'impression ;
  • la technologie d'impression ;
  • la couleur ou le monochrome ;
  • les formats supportés ;
  • la connectivité ;
  • les variantes de gamme ;
  • les informations de consommables lorsqu'elles servent à distinguer le produit, sans confondre l'imprimante et ses cartouches ou toners.

Frontière architecturale

Données normalisées
        ↓
Détection Printer
        ↓
Règles métier Printer
        ↓
preuves / candidats / conflits
        ↓
Resolver générique
        ↓
Projection

La verticale Printer ne doit pas :

  • écrire directement en base ;
  • créer ou modifier une projection elle-même ;
  • appeler le Frontend ;
  • piloter le Runtime ;
  • transformer un consommable en imprimante par défaut ;
  • forcer une résolution lorsque le modèle ou la famille restent ambigus.

Attributs structurants à valider

Avant industrialisation, les données réelles doivent permettre de confirmer quels attributs sont réellement discriminants.

Candidats typiques à auditer :

Attribut Exemples Risque métier
marque HP, Canon, Epson, Brother conflit fort si incompatible
gamme / modèle LaserJet Pro M404, EcoTank ET-2850 identité principale
technologie laser, jet d'encre, thermique peut séparer des familles
couleur couleur, monochrome variante ou sous-famille selon produit
multifonction impression seule, scan/copie différence produit potentiellement structurante
format A4, A3 différence matérielle potentielle
connectivité USB, Wi-Fi, Ethernet enrichissement ou variante selon modèle
consommable cartouche, toner, réservoir ne doit pas devenir l'identité de l'imprimante

La documentation ne fixe pas ces attributs comme contrat CURRENT tant qu'ils n'ont pas été validés sur des échantillons réels.

Conflits à préserver

La future verticale doit au minimum savoir laisser non résolus les cas où les preuves se contredisent.

Exemples de situations à traiter explicitement :

  • marque incompatible ;
  • référence de modèle différente ;
  • imprimante contre consommable ;
  • imprimante contre scanner autonome ;
  • technologie d'impression incompatible ;
  • format ou fonction structurante contradictoire ;
  • titre marchand trop générique pour départager plusieurs modèles.

Les états canoniques restent :

  • resolved ;
  • unknown ;
  • ambiguous ;
  • conflict.

Reason codes

Une industrialisation devrait produire des codes de raison stables et indépendants du texte d'affichage, par exemple :

printer.model.exact
printer.model.unknown
printer.family.ambiguous
printer.consumable.excluded
printer.technology.conflict
printer.brand.conflict

Ces exemples constituent un TARGET de lisibilité, pas des identifiants Runtime certifiés.

Projection

La projection doit uniquement matérialiser une décision déjà prise par les couches métier.

Elle peut exposer les attributs Printer utiles à la lecture, mais elle ne doit pas :

  • résoudre un modèle ;
  • convertir un consommable en imprimante ;
  • corriger silencieusement un conflit ;
  • inventer un attribut manquant.

Le Builder prépare la représentation ; le Write Service ou le writer dédié la persiste.

Méthode d'industrialisation

Avant toute activation :

  1. inventorier les données de plusieurs marchands ;
  2. séparer imprimantes, scanners, consommables et accessoires ;
  3. mesurer les références réellement fiables ;
  4. définir les règles locales déterministes ;
  5. lancer des audits read-only ;
  6. inspecter les cas unknown, ambiguous et conflict ;
  7. simuler les changements ;
  8. mesurer les KPI et les régressions ;
  9. intégrer le module au Runtime uniquement après validation.

Diagnostic

Si une imprimante est mal restituée dans le catalogue, ne pas commencer par modifier le template.

Vérifier dans l'ordre :

source marchande
    ↓
normalisation
    ↓
détection de verticale
    ↓
preuves Printer
    ↓
Resolver
    ↓
projection
    ↓
Read Service / Adapter
    ↓
Frontend

Une erreur visible n'indique pas automatiquement une erreur Frontend.

Invariants

  1. Printer reste isolée du Domain Core générique.
  2. Une référence de consommable n'est pas une identité d'imprimante.
  3. L'incertitude reste explicite.
  4. Aucune règle Printer n'écrit directement.
  5. La navigation publique ne prouve pas l'activation du module.
  6. Toute activation Runtime doit être précédée d'audits reproductibles.

Voir aussi