Domain Driven Design

Domain Driven Design

Acquérir les pratiques d’une conception logicielle orientée métier

Référence IGL-DDD-F
Durée 3 jour(s)

Pour une session intra ou sur mesure

Demander un devis
Débutant Génie logiciel

Le développement logiciel est employé généralement pour automatiser des processus existants ou pour fournir des solutions à des problèmes métier. Le Domain-Driven Design repose sur une idée simple : pour créer un bon logiciel, il est indispensable qu'il reflète le domaine métier pour lequel il est conçu, qu'il en incorpore les concepts, les process, les éléments et qu'il saisisse avec précision, leurs relations. 

Cette formation vous apprend les fondamentaux du DDD et sa mise en œuvre pratique et concrète dans vos logiciels. 

Objectifs pédagogiques

Les objectifs pour un candidat ayant suivi cette formation sont :

  • Maîtriser l’approche Domain-Driven Design (DDD) : pourquoi ? bénéfices ? principes clés.
  • Étudier et mettre en œuvre les building blocks du DDD.
  • Étudier et mettre en œuvre les principes de conception : supple design et strategic design.
  • Étudier les architectures permettant de mettre en œuvre une approche DDD.
  • Échanger sur les aspects concrets et pratiques du DDD avec des retours d’expérience.

Public concerné

  • Architectes.
  • Développeurs senior ou junior.
  • Team Leader.
  • Chef de Projets.

Prérequis

  • Connaissance des concepts et d'un langage objet (Java, C#).
  • Expérience du développement logiciel en entreprise.

Programme de la formation

Introduction à l'approche DDD

  • Origine, définitions et bénéfices.
  • Principes clés de l’approche.
  • Qu'est-ce que l'activité de conception ?

Avant de concevoir : pourquoi ce logiciel ?

  • Définir la vision du projet.
  • Pourquoi le logiciel est développé ?
  • Présentation des techniques :
    • Feature Injection.
    • Impact Mapping.
    • User Story Mapping.
    • Mental Models.

Avant de concevoir : explorer le domaine et spécifier le comportement du logiciel

  • Des scénarios avec des exemples 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 scénarios : dépendances, mutualisation, gestion des données.
  • Comment exprimer les règles métiers dans les scénarios ?

Fondamentaux de modélisation et gestion de la complexité

  • Qu'est-ce qu'un modèle ? papier/crayon ou outil de modélisation ?
  • Qu'est-ce que la complexité ? outils pour la gérer.
  • 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.
  • Exercices pratiques de mise en œuvre des Entity, Value objects et Repository.

DDD supple design pour un logiciel évolutif et testable

  • La gestion des dépendances.
  • La gestion d'états.
  • Séparation des responsabilités.
  • Encapsulation 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 operations.

Architectures pour une approche DDD

  • Modulariser le domaine
  • Architecture Hexagonale : inversion de dépendances, le Domaine au coeur 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.
  • Gestion de la persistance avec le DDD : aspects pratiques.

DDD strategic design : intégrer le logiciel dans son écosystème, intégrer les équipes entre-elles

  • Notion de Bounded Context.
  • Comment intégrer différents modèles ?
  • Context Map
  • Relations entre systèmes et équipes :
    • Shared Kernel.
    • Anticorruption Layer.
    • Conformist.
    • Customer/Supplier.
    • Separate Ways.
    • Open Host.
    • Published Language.

• Intégrer des systèmes Legacy : stratégie d’intégration, stratégie de refactoring

Moyens pédagogiques

Travaux pratiques.