Maîtriser les pratiques d’une conception logicielle orientée métier
Description de la formation Domain Driven Design (DDD)
Un logiciel se doit d’être au service d’un domaine métier. Le but du Domain Driven Design, appelé DDD est de réaliser des logiciels plus performants et de manière plus fluide en se concentrant davantage sur le domaine métier que sur la technologie.
Un logiciel se voit être adapté à son domaine quand sa capacité à traiter les dysfonctionnements liés au domaine est bonne.
Le Domain Driven Design est une approche des techniques de conception pour gérer la complexité du domaine et aligner le logiciel sur les concepts métiers qu’il manipule.
Cette formation de trois jours vous permettra de vous familiariser avec cette approche.
Bulletin d’
inscription Demande de
devis Détail du
programme
Programme de la formation Domain Driven Design (DDD)
- Introduction
- Origine, définitions et avantages
- Principes clés de la méthode
- Qu’est ce que l’activité de conception ?
- Avant la conception : pourquoi le DDD ?
- Définition de la vision de l’objectif
- Pourquoi le logiciel est-il développé ?
- Présentation des techniques : Feature Injection Impact Mapping User Story , Mapping Mental Models
- Avant la conception : explorer le domaine et spécifier le comportement du logiciel
- Des scénarios avec des schémas pour explorer le domaine
- Event Storming: Les événement dans le temps pour explorer le domaine
- Exprimer le comportement attendu avec des exemples au format BDD (Behavior Driven Development : Given/When/Then)
- Organisation des exemples : dépendances, mutualisation, gestion des données
- Comment exprimer les règles métiers dans les scénarios ?
- Fondamentaux de la modélisation et gestion de la difficulté
- Définition d’un modèle :papier/crayon ou outil de modélisation ?
- Définition de la complexité
- Outils de gestion
- Les aspects pratiques : communication, intentions, forme (graphique, textuel), gestion collective du modèle
- Les building blocks du DDD
- L’ubiquitous language
- Building Blocks du DDD : La gestion d’état avec les Value Object et les Entity
- L’accès aux Entity avec les Repositories Factory Service Module Aggregate Domain Event
- DDD Supple Design pour un logiciel évolutif à tester
- Gérer les dépendances
- Gérer les états
- Comment séparer des responsabilités ?
- Regroupement de données et Interface
- Présentation du Paradigme Fonctionnel : Lazyness, Immutabilité, Fonctions Pures
- DDD Supple Design Intention-revealing interface Standalone classes Side
- Effect free function Assertions Conceptual contours Closure on operation
- Architectures pour une approche DDD
- Moduler le domaine
- Architecture Hexagonale : inversion de dépendances, le Domaine au cœur de l’architecture, utilisation des frameworks d’injection de dépendances avec le DDD (Spring, etc.)
- Architecture Événementielle : CQRS, Event Sourcing, lien avec le DDD
- Architecture Microservice avec le DDD : REST et SOA, apport du DDD
- Gérer la persistance avec le DDD : cas pratiques
- DDD STRATEGIC DESIGN : intégrer le logiciel dans son écosystème, intégrer les équipes entre elles
- Notion de Bounded Context
- Intégration de différents modèles
- Context Map
- Relations entre systèmes et équipes :Shared Kernel Anticorruption Layer Conformist Customer/SupplierSeparate WaysOpen HostPublished Language
- Intégration des systèmes Legacy : stratégie d’intégration, stratégie de refactoring
|