Public cible
Débutants, étudiants et professionnels qui souhaitent acquérir une pratique structurée dans ce domaine.
Développer des composants métier
Développer des composants métier
Se connecter pour s'inscrireJavaScript et TypeScript avancé
Découper un domaine en services réutilisables, explicites et testables avec des contrats et une gestion fiable des erreurs.
-
-
Objectifs
Comprendre les notions essentielles et les appliquer dans un projet vérifiable.
-
Prérequis
Aucune connaissance préalable n’est strictement obligatoire ; les prérequis détaillés sont précisés dans les ateliers.
-
Niveau
Bac+2
-
Ressources
- Documentation officielle et références citées dans les ateliers.
- Exercices, examens et projet de synthèse du catalogue.
-
Validation des compétences
La validation repose sur les évaluations actives et les livrables pratiques du cours.
-
Besoins techniques
Un ordinateur, un navigateur et les outils indiqués dans le premier atelier sont suffisants pour commencer.
Modules associés
Exercices, examens et projets
Composants métier
Projet
Projet composants
Construire une bibliothèque métier documentée.
Livrables :
- Code
- Tests
- Documentation
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.
À la fin du cours
- Identifier les responsabilités et les contrats métier.
- Écrire des services petits, testables et explicites.
- Gérer les dépendances, erreurs et effets de bord.
- Documenter et versionner les API internes.
Organisation
Le cours articule responsabilités, contrats, erreurs et tests d’intégration.
Prérequis : Programmation orientée objet, exceptions et tests unitaires.
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
Point de contrôle : Chaque composant peut être remplacé par un doublure dans un test unitaire.
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; }
Point de contrôle : Un changement de fournisseur ne modifie pas les règles métier.
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
- Valider les préconditions.
- Appliquer la règle métier.
- Enregistrer et notifier après commit.
Point de contrôle : Un retry ne double pas une commande ni une notification.
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));
Point de contrôle : Le test échoue si une règle métier ou un effet de bord change sans révision.
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.
Critère de réussite : Le composant est validé lorsqu’il respecte son contrat, reste testable sans infrastructure et gère une nouvelle tentative sans doublon.
Publié le 29/11/2025