Composants métier

Syllabus

1. Description

2. Objectifs

3. Validations de compétences

4. Public cible

   Aucun public cible spécifié pour ce module.

5. Besoins techniques

6. Prérequis

   • Aucun prérequis

7. Niveau

8. Historique du module

   Aucune action enregistrée

Développer des composants métier

Découper un domaine en composants cohérents, réutilisables et testables, puis les intégrer sans créer de dépendances cachées.

Découper par responsabilité

Un composant doit avoir une raison claire d’exister et une seule responsabilité principale. Un service qui valide, envoie un e-mail, modifie la base et construit une réponse devient difficile à tester.

Regrouper les règles qui évoluent ensemble, puis séparer les adaptateurs techniques. Le nom de la classe doit décrire le cas d’usage plutôt qu’un détail d’implémentation.

PricingService, OrderWorkflow, NotificationPort

Contrats et dépendances

Définir les entrées, sorties, erreurs et effets attendus. Une interface de port permet au domaine de dépendre d’une capacité sans connaître le fournisseur choisi.

Rendre les dépendances explicites par injection et éviter les services globaux. Une dépendance optionnelle doit avoir un comportement défini, pas une valeur surprise.

interface PaymentPort { public function charge(Money $amount, PaymentReference $reference): Receipt; }

Erreurs et effets de bord

Distinguer une règle métier refusée, une dépendance indisponible et une erreur technique. Les notifications et la journalisation ne doivent pas masquer l’échec principal.

Rendre les effets de bord idempotents lorsqu’un retry est possible. Enregistrer un identifiant de corrélation et conserver une trace de la décision prise.

Méthode

1. Valider les préconditions.
2. Appliquer la règle métier.
3. Enregistrer et notifier après commit.

Tests et documentation

Tester le contrat public et les règles aux frontières. Un test doit d’abord vérifier le résultat, puis les effets attendus.

Documenter les exemples, les préconditions et les raisons des décisions. Une API interne sans contrat écrit devient un piège pour l’équipe suivante.

it('refuse une commande déjà payée', fn () => expect($handler(...))->toThrow(DomainException::class));

Livrables et validation

Le livrable doit montrer une compréhension personnelle, des choix explicités et une vérification par un cas de test ou une procédure reproductible.

• Une cartographie des composants et de leurs contrats.
• Deux composants implémentés avec tests.
• Une documentation des erreurs et des effets de bord.
• Un exemple d’intégration dans un parcours réel.

Exercices, examens et projets