Architecture logicielle multicouche
Architecture logicielle multicouche
Se connecter pour s'inscrireVotre progression
0 / 0 étapes complétées
0
Syllabus
-
-
Objectifs
-
Validations de compétences
-
Public cible
Aucun public cible spécifié pour ce module.
-
Besoins techniques
-
Prérequis
- Aucun prérequis
-
Niveau
-
Historique du module
Aucune action enregistrée
Architecture logicielle multicouche
Organiser une application pour que le domaine métier reste indépendant du HTTP, de la base et des détails techniques.
À la fin du cours
- Placer chaque responsabilité dans la couche qui lui appartient.
- Respecter le sens des dépendances et limiter les effets de bord.
- Introduire transactions, repositories et injection de dépendances.
- Tester les règles métier sans démarrer le serveur web.
Organisation
Le cours suit la frontière du domaine, les cas d’usage, la persistance et les tests d’assemblage.
Prérequis : Programmation orientée objet et notions HTTP, SQL et tests.
Comprendre les couches
La couche présentation traduit les requêtes et les réponses. La couche application orchestre les cas d’usage. Le domaine contient les règles qui restent vraies sans framework. L’infrastructure fournit les implémentations techniques.
Une dépendance pointe vers une couche plus stable : le domaine ne connaît ni Doctrine, ni HTTP, ni le fournisseur de messagerie. Cette règle réduit les effets de bord et facilite les migrations.
Présentation → Application → Domaine ← Infrastructure
Point de contrôle : Une règle métier peut être testée sans annotation Doctrine ni request HTTP.
Modéliser les cas d’usage
Un service applicatif représente une intention utilisateur ou métier. Il charge les objets nécessaires, vérifie les préconditions, applique les règles et renvoie un résultat explicite.
Ne pas placer toutes les requêtes dans un contrôleur : cela rend le cas d_usage difficile à réutiliser et à tester. Inversement, un service ne doit pas exposer directement les entités de persistance comme contrat public.
final class CreateOrderHandler { public function __invoke(CreateOrder $command): OrderResult { /* ... */ } }
Point de contrôle : Chaque cas d’usage possède une entrée, une sortie et des erreurs métier identifiables.
Isoler la persistance et les transactions
Le repository traduit les besoins du domaine en requêtes. La transaction commence au plus près du cas d’usage et se termine après l’écriture cohérente de ses données.
Éviter les requêtes N+1, sélectionner uniquement les champs nécessaires et protéger les écritures concurrentes. Un rollback doit laisser la base dans son état initial et être observé dans les tests.
$this->connection->beginTransaction(); try { /* use case */; $this->connection->commit(); } catch (Throwable $e) { $this->connection->rollBack(); throw $e; }
Point de contrôle : Un test d’échec prouve qu’aucune donnée partielle ne reste après une exception.
Tester les frontières
Tester les règles métier avec des objets et des doublures simples, puis les repositories avec une base dédiée. Les tests d’intégration vérifient que l’assemblage réel fonctionne.
Documenter les décisions d’architecture avec un diagramme, les dépendances interdites et le sens de migration. Une règle non automatisée finit toujours par être contournée.
Méthode
- Écrire un test du domaine.
- Ajouter un test d’intégration du repository.
- Vérifier la transaction et le contrat HTTP.
Point de contrôle : La suite détecte une règle de dépendance inversée et un cas de rollback.
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.
- Un diagramme de couches et la matrice des dépendances.
- Un squelette de cas d’usage avec ports et adaptateurs.
- Des tests unitaires et d’intégration documentés.
- Une procédure de migration et de gestion des erreurs.
Critère de réussite : Le squelette est validé si le domaine reste indépendant, les cas d’usage sont testables et les transactions sont prouvées par un test d’échec.