Your SlideShare is downloading. ×
Alt.Net France - Domain Driven Design - 2 Dec 2008
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

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

1,309
views

Published on

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

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

Published in: Technology

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,309
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
52
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Transcript

    • 1. DOMAIN DRIVEN DESIGN DDD pour les intimes… Julien Lavigne du Cadet et Gauthier Segay, 2 Décembre 2008
    • 2. 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
    • 3. SONDAGE
      • Qui à entendu parler du DDD?
      • Qui pratique le DDD sur un projet?
    • 4. ORIGINE...
      • Expression popularisée par Eric Evans en 2003 dans :
    • 5. UN CONCEPT RÉCENT!
    • 6. MAIS C’EST QUOI AU JUSTE?
    • 7. 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
    • 8. UN CONTRE EXEMPLE : THE SMART UI “ANTI-PATTERN”
    • 9. UN CONTRE EXEMPLE : THE SMART UI “ANTI-PATTERN”
    • 10. 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
    • 11. UN EXEMPLE...
      • Avant Refactoring...
      • Après...
    • 12. LES “BUILDING BLOCKS”
      • Architecture en couche
      • POCO as a lifestyle
      • Entities, Value Objects
      • Root Aggregates
      • Repositories
      • Services
    • 13. ARCHITECTURE EN COUCHE
      • Le domaine est indépendant !
    • 14. POCO AS A LIFESTYLE
      • POCO = Plain Old CLR Objects
    • 15. 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
    • 16. ENTITIES & VALUE OBJECTS
      • Comment classifier un objet du domaine entre value object et entité?
      Cela dépend du domaine!
    • 17. 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
    • 18. REPOSITORIES
      • Expose et encapsule les opérations de persistance pour les root aggregates uniquement
    • 19. REPOSITORIES
      • Ex:
    • 20. 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
    • 21. SERVICES
      • Ex:
    • 22. UNE VUE D’ENSEMBLE
    • 23. 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
    • 24. POUR ALLER PLUS LOIN: