Mettez (enfin) en place le DDD
Apprenez et implémentez les modèles de conception simples pour satisfaire des besoins complexes
Pourquoi choisir les modèles du DDD pour développer un logiciel?
Le but d’un logiciel est de satisfaire au maximum le besoin du client.
Le DDD (Domain-Driven Design) , en français, conception orientée par le métier, propose un ensemble de pratiques et méthodes aidant les concepteurs logiciels à se focaliser plus facilement, sur la conception d’une solution qui s’aligne aux besoins fonctionnels.
L’application de ces méthodes intensifie la collaboration des experts métiers et techniques; facilitant ainsi la compréhension du problème et la mise en place de la résolution.
De plus, ces méthodes poussent les concepteurs à intégrer plus naturellement l’architecture en microservices, facteur capital de l’extensibilité d’un produit logiciel.
Tout ceci fait du DDD une philosophie de conception pour réaliser de puissantes solutions pour le métier et par le métier. Et ce, en ayant un produit parfaitement extensible.
Achetez ce cours complet pour seulement 150 €
Apprenez le DDD par la pratique
La philosophie DDD a été présentée au monde il y a plus de 15 ans. Cependant, sa perception demeure encore beaucoup trop théorique, sinon mal appliquée, d’où sa faible adoption.
Pour en saisir la quintessence, il faut se lancer dans une phase de réapprentissage avec application à des projets et besoins du monde réel. C’est ce que je vous propose pour ce parcours.
Bien sûr, nous allons commencer par présenter les grandes catégories de méthodes proposées par le DDD, puis, en sélectionner quelques-unes, pour rapidement les mettre en pratique en construisant une application de qualité, servant un métier délicat.
Implémentez les méthodes du DDD étape par étapes
Durant chaque module, vous réalisez un livrable.
Les leçons débutent par de la théorie suivie d’exercices pratiques qui participent, peu à peu, à la réalisation du livrable.
À la fin des 3 modules, vous aurez alors 3 livrables qui forment ensemble la pièce maîtresse de votre maîtrise du DDD.
La pratique de codage réelle à travers un projet du monde réel est la meilleure façon d'apprendre un concept complexe tel que le DDD
Le DDD c’est aussi du code
Mon nom est Philippe, Ingénieur logiciel passionné. Je programme depuis plus de 10 ans déjà et je serai votre instructeur tout au long de ce parcours.
Nous aurons tout naturellement des parties pratiques nécessitant du code. Notamment pour développer des micro-services, alignés à une architecture hexagonale.
Ce cours est axé sur les bases du DDD. Celles-ci sont essentielles pour aller de l'avant, comprendre les aspects les plus avancés et créer des systèmes plus complexes
Qu’allez-vous apprendre ?
Si je me suis continuellement intéressé au DDD, c’est parce que j’ai eu un très bon instructeur. J’utiliserai donc la même méthode par laquelle j’ai appris pour vous passer l’essentiel des éléments dont vous aurez besoin pour enfin appliquer le DDD correctement à un vrai projet.
1. Bien démarrer avec le Domain-Driven Design (DDD)
3 Leçons
- Qu’est-ce que le DDD en réalité ?
- Dois-je appliquer le DDD ? 2 sous-leçons
2. Utilisez les patterns stratégiques du DDD pour distiller le besoin métier
11 Leçons
- Le rôle des patterns stratégiques
- Posez des questions puissantes pour mieux comprendre le besoin
- Enrichissez le besoin métier grâce aux questions puissantes
- Réalisez l’ ”Event Storming” afin d’extraire le concentré du besoin métier: 5 sous-leçons
- Isolez les besoins métier avec les “Bounded Context” en respectant un lexique compréhensible de tous: “Ubiquitous Language”
- Esquissez une architecture hexagonale pour chaque bounded context
- Faites le bon choix d’architecture entre les bounded contexts: “Context Mapping”
3. Mettez en pratique les modèles de conception tactiques du DDD
11 Leçons
- Le rôle des patterns tactiques
- Utilisez pas à pas les agrégats pour déterminer ce qu’il faut coder au sein des “bounded-context” : 2 sous-leçons
- Installez les outils et prérequis
- Implémenter , via le TDD les besoins métiers dans les bounded contexts
- pour Implémenter la complexité technique sans polluer le domaine : 4 sous-leçons
- Tester de bout en bout