Alt.Net France - Domain Driven Design - 2 Dec 2008

1 572 vues

Publié le

Présentation sur le Domain Driven Design pour Alt.net chez Microsoft.

Publié dans : Technologie
0 commentaire
2 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 572
Sur SlideShare
0
Issues des intégrations
0
Intégrations
405
Actions
Partages
0
Téléchargements
57
Commentaires
0
J’aime
2
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Alt.Net France - Domain Driven Design - 2 Dec 2008

    1. 1. DOMAIN DRIVEN DESIGN DDD pour les intimes… Julien Lavigne du Cadet et Gauthier Segay, 2 Décembre 2008
    2. 2. QUI SOMMES NOUS? <ul><li>Julien Lavigne du Cadet : </li></ul><ul><ul><li>Ex-Entrepreneur </li></ul></ul><ul><ul><li>Expérience en finance de marché </li></ul></ul><ul><ul><li>Blog : www.thedotnetfrog.fr </li></ul></ul><ul><li>Gauthier Segay : </li></ul><ul><ul><li>Ex-Entrepreneur aussi ;-) </li></ul></ul><ul><ul><li>Concepteur logiciel chez Logica </li></ul></ul>
    3. 3. SONDAGE <ul><li>Qui à entendu parler du DDD? </li></ul><ul><li>Qui pratique le DDD sur un projet? </li></ul>
    4. 4. ORIGINE... <ul><li>Expression popularisée par Eric Evans en 2003 dans : </li></ul>
    5. 5. UN CONCEPT RÉCENT!
    6. 6. MAIS C’EST QUOI AU JUSTE?
    7. 7. DOMAIN DRIVEN DESIGN <ul><li>Focus sur le domaine </li></ul><ul><li>Regrouper tout le savoir sur un domaine donné au sein d’une même couche </li></ul><ul><li>Développer un langage partagé par l’équipe de développement ET le business </li></ul><ul><ul><li>=> Ubiquitous language </li></ul></ul><ul><li>Modèlisation purement orientée objet </li></ul>
    8. 8. UN CONTRE EXEMPLE : THE SMART UI “ANTI-PATTERN”
    9. 9. UN CONTRE EXEMPLE : THE SMART UI “ANTI-PATTERN”
    10. 10. LES AVANTAGES <ul><li>Regrouper le savoir fonctionnel au même endroit : </li></ul><ul><ul><li>Meilleure compréhension </li></ul></ul><ul><ul><li>Meilleure maintenabilité </li></ul></ul><ul><ul><li>DRY : Don’t Repeat Yourself </li></ul></ul><ul><ul><li>Plus stable que les autres couches </li></ul></ul><ul><li>Faciliter les tests : </li></ul><ul><ul><li>Isolation </li></ul></ul>
    11. 11. UN EXEMPLE... <ul><li>Avant Refactoring... </li></ul><ul><li>Après... </li></ul>
    12. 12. LES “BUILDING BLOCKS” <ul><li>Architecture en couche </li></ul><ul><li>POCO as a lifestyle </li></ul><ul><li>Entities, Value Objects </li></ul><ul><li>Root Aggregates </li></ul><ul><li>Repositories </li></ul><ul><li>Services </li></ul>
    13. 13. ARCHITECTURE EN COUCHE <ul><li>Le domaine est indépendant ! </li></ul>
    14. 14. POCO AS A LIFESTYLE <ul><li>POCO = Plain Old CLR Objects </li></ul>
    15. 15. ENTITIES & VALUE OBJECTS <ul><li>Entity : </li></ul><ul><ul><li>possède une identité propre </li></ul></ul><ul><ul><li>représente un objet du domaine </li></ul></ul><ul><ul><li>encapsule tout ou partie de la logique métier </li></ul></ul><ul><ul><li>ex: Customer, Bill, Product </li></ul></ul><ul><li>Value Object : </li></ul><ul><ul><li>sans identité propre (peut être substitué) </li></ul></ul><ul><ul><li>généralement utilisé comme attribut ou paramètre, peut aussi référencer des entités </li></ul></ul><ul><ul><li>ex: PostalAddress, URL, IPAddress, DateTimeOffset, CurrencyAmount </li></ul></ul>
    16. 16. ENTITIES & VALUE OBJECTS <ul><li>Comment classifier un objet du domaine entre value object et entité? </li></ul>Cela dépend du domaine!
    17. 17. ROOT AGGREGATE <ul><li>est la racine d’un groupe d’objets représentant une unité logique </li></ul><ul><li>est une entité </li></ul><ul><li>permet la définition : </li></ul><ul><ul><li>de relations d’appartenance entre les objets du groupe </li></ul></ul><ul><ul><li>d’opérations impactant plusieurs entités </li></ul></ul>
    18. 18. REPOSITORIES <ul><li>Expose et encapsule les opérations de persistance pour les root aggregates uniquement </li></ul>
    19. 19. REPOSITORIES <ul><li>Ex: </li></ul>
    20. 20. SERVICES <ul><li>Regroupe les opérations qui n’appartiennent pas à un object spécifique </li></ul><ul><li>Agit souvent sur plusieurs objets du modèle </li></ul><ul><li>Stateless </li></ul><ul><li>Recommendations: </li></ul><ul><ul><li>ne pas exposer de couplage avec la couche infrastructure </li></ul></ul>
    21. 21. SERVICES <ul><li>Ex: </li></ul>
    22. 22. UNE VUE D’ENSEMBLE
    23. 23. AUTRES PRATIQUES CLEFS <ul><li>Intention Revealing Interfaces : </li></ul><ul><ul><li>Principle of least surprise: </li></ul></ul><ul><ul><ul><li>lisibilité des signatures, des intentions </li></ul></ul></ul><ul><li>Refactoring : </li></ul><ul><ul><li>le modèle doit toujours représenter le savoir </li></ul></ul><ul><li>Validation </li></ul><ul><ul><li>Ne pas dupliquer la logique, maintenir l’intégrité du domaine </li></ul></ul><ul><li>Mapping Objet-Relationnel </li></ul><ul><ul><li>Plus besoin d’écrire du SQL </li></ul></ul><ul><li>Dependency Injection – Inversion of Control </li></ul><ul><ul><li>Plus besoin d’instancier ses dépendances, il suffit de les exposer </li></ul></ul>
    24. 24. POUR ALLER PLUS LOIN:

    ×