Introduction au DDD

Nicolas Eeckeloo

Les phrases qu'on entend

  • “J’en ai déjà entendu parlé … mais je ne vois pas trop ce que c’est”
  • “Ca doit avoir un rapport avec le TDD.”
  • “Hein ? T’as un problème avec la touche D !”
  • “Le DDD, j’ai lu l’article Wikipédia, c’est de la merde”

Le DDD, ce n'est pas :

  • une nouvelle technologie révolutionnaire
  • une méthode miracle pour architecturer une application
  • un outil à la mode qui va bientôt devenir obsolète
  • des entités Doctrine sans les getters/setters

The heart of software is its ability to solve domain-related problems to its user

Eric Evans

Le DDD, c'est quoi ?

  • une approche pour concevoir des logiciels de qualité
  • des outils de conception pour atteindre les objectifs métiers
  • développe la connaissance métier
  • utilise la technologie pour créer de la valeur
  • comprendre l'activité de votre entreprise afin de produire un langage commun

Pourquoi le Domain-Driven Design ?

  • un seul et unique langage

  • priorités logicielles alignées avec les priorités métier

  • apprentissage du métier par tous

  • contribution de tous à l'étude du métier

  • pas de traductions nécessaires entre les différentes parties prenantes

  • délivrer de la valeur de manière continue

  • un framework pour le strategic et tactical design

Ubiquitous Language

Adjective : Existing or being everywhere, especially at the same time; omnipresent.

[yoo-bik-wi-tuh s]

A language structured around the domain model and used by all team members to connect all the activities of the team with the software.

Eric Evans

Quand et où l'utiliser ?

  • user stories
  • réunions de projet
  • emails
  • planning
  • documentation
  • code source

Avantages

  • risques d’incompréhensions diminués

  • meilleure communication entre les parties prenantes du projet

  • connaissance du métier présent dans le code de manière explicite

  • code source plus facile à comprendre (meilleure maintenabilité et évolutivité du code)

Strategic vs Tactical Design

Strategic Design First

  • plus axé sur le domaine et l'importance de la connaissance du domaine
  • impossible d'atteindre l'objectif sans connaissance approfondie du domaine
  • développeurs qui se focalisent à tort sur le Tactical Design
  • les Stategical Patterns répondent davantage aux problématiques des projets complexes (Bounded Context, Context Mapping, Ubiquitous Language)

Sub-domains

  • Generic Domain
  • Supporting Domain
  • Core Domain

Generic Domain

  • parties du système qui facilitent le métier, mais qui ne font pas partie du coeur de métier (abonnement, facturation)

  • concepts critiques mais qui ne font pas partie du coeur de métier

  • parties du métier qui peuvent éventuellement être outsourcées ou déléguées à une solution SaaS

Supporting Domain

  • parties du systèmes également nécessaires

  • fonctions de support directement relatives au métier principal

  • code de qualité et parfaitement architecturé pas nécessaire

  • possibilité d'outsourcer cette partie ou d'assigner des développeurs peu expérimentés

  • maintenir une séparation forte avec le coeur de métier (context mapping)

Core Domain

  • partie la plus critique et fondamentale pour le métier

  • constitue l'avantage concurrentiel et l'essence même du produit

  • domaine sur lequel vous souhaitez voir travailler les personnes les plus expérimentées

Core Domain

Selon Eric Evans, le core domain devrait fournir environ 20% de la valeur totale du produit, représenter environ 5% de la base de code, et correspondre à environ 80% de l'effort total.

Context Mapping

Behaviour Driven Development

BDD is the art of using examples in conversations to illustrate behaviour

Liz Keogh

By embedding Ubiquitous Language in your scenarios, your scenarios naturally become your domain model

Konstantin Kudryashov

Modelling by example

  • la meilleure manière de comprendre le métier est de discuter autour d'exemples
  • écrire des scénarios qui illustre des situations réelles
  • écrire des scénarios qui utilisent l'ubiquitous language
  • piloter le code par ces exemples

Event Storming

  • réunir les personnes qui ont des questions et celles qui ont des réponses

  • aborder tous les composants importants le plus tôt possible afin de découvrir les problèmes potentiels

  • toucher toutes les personnes concernées le plus tôt possible, en mettant à profit ce qui ressort des interactions entre chacune

Merci

Made with Slides.com