DOMAIN DRIVEN DESIGNDDD pour les intimes…

Julien Lavigne du Cadet et Gauthier Segay, 2 Décembre 2008

QUI SOMMES NOUS?

Julien Lavigne du Cadet : Ex-Entrepreneur Expérience en finance de marché Blog : www.thedotnetfrog.fr

Gauthier Segay : Ex-Entrepreneur aussi ;-) Concepteur logiciel chez Logica

SONDAGE

Qui à entendu parler du DDD? Qui pratique le DDD sur un projet?

ORIGINE...

Expression popularisée par Eric Evans en 2003 dans :

UN CONCEPT RÉCENT!

MAIS C’EST QUOI AU JUSTE?

DOMAIN DRIVEN DESIGN

Focus sur le domaine

Regrouper tout le savoir sur un domaine donné au sein d’une même couche

Développer un langage partagé par l’équipe de développement ET le business ◦ => Ubiquitous language

Modèlisation purement orientée objet

UN CONTRE EXEMPLE : THE SMART UI “ANTI-PATTERN”

UN CONTRE EXEMPLE : THE SMART UI “ANTI-PATTERN”

LES AVANTAGES

Regrouper le savoir fonctionnel au même endroit : Meilleure compréhension Meilleure maintenabilité DRY : Don’t Repeat Yourself Plus stable que les autres couches

Faciliter les tests : Isolation

UN EXEMPLE...Avant Refactoring... Après...

LES “BUILDING BLOCKS”

Architecture en couchePOCO as a lifestyleEntities, Value ObjectsRoot AggregatesRepositoriesServices

ARCHITECTURE EN COUCHE

Le domaine est indépendant !

POCO AS A LIFESTYLE

POCO = Plain Old CLR Objects

ENTITIES & VALUE OBJECTS

Entity : possède une identité propre représente un objet du domaine encapsule tout ou partie de la logique métier ex: Customer, Bill, Product

Value Object : sans identité propre (peut être substitué) généralement utilisé comme attribut ou paramètre, peut

aussi référencer des entités ex: PostalAddress, URL, IPAddress, DateTimeOffset,

CurrencyAmount

ENTITIES & VALUE OBJECTS

Comment classifier un objet du domaine entre value object et entité?

Cela dépend du domaine!

ROOT AGGREGATE

est la racine d’un groupe d’objets représentant une unité logique

est une entité permet la définition :

de relations d’appartenance entre les objets du groupe d’opérations impactant plusieurs entités

REPOSITORIES

Expose et encapsule les opérations de persistance pour les root aggregates uniquement

REPOSITORIES

Ex:

SERVICES

Regroupe les opérations qui n’appartiennent pas à un object spécifique

Agit souvent sur plusieurs objets du modèle Stateless

Recommendations: ne pas exposer de couplage avec la couche infrastructure

SERVICES

Ex:

UNE VUE D’ENSEMBLE

AUTRES PRATIQUES CLEFS

Intention Revealing Interfaces : Principle of least surprise:

lisibilité des signatures, des intentions

Refactoring : le modèle doit toujours représenter le savoir

Validation Ne pas dupliquer la logique, maintenir l’intégrité du domaine

Mapping Objet-Relationnel Plus besoin d’écrire du SQL

Dependency Injection – Inversion of Control Plus besoin d’instancier ses dépendances, il suffit de les

exposer

POUR ALLER PLUS LOIN: