Introduction au Domain Driven Design

Click here to load reader

  • date post

    22-Apr-2015
  • Category

    Business

  • view

    13.980
  • download

    6

Embed Size (px)

description

Introduction au Domain Driven Design

Transcript of Introduction au Domain Driven Design

  • 1. Le Domain Driven Design Une conception pilote par le domaine pour lentreprise Page Sami Jaber (webmaster du site DotNetGuru.org et fondateur de DNG-Consulting)
  • 2. Le Symposium DNG
    • 4 me dition, plus de 2000 inscriptions
      • Prsence de Bill Gates en 2005
      • Erik Meijer en 2008
    • Partenariat de longue date avec Microsoft (avec dabord Marc Gardette et aujourdhui Franois Merand)
    • Objectifs
      • Dvelopper des sujets dentreprise
      • Anticiper les volutions des architectures de demain
      • Prendre du recul sur le marketing des diteurs
    • Le Symposium a contribu :
      • Dmocratiser les architectures en couches
      • Faire connatre le mapping O/R, lAOP, SOA, les pratiques agiles
  • 3. Pourquoi encore parler darchitecture en 2008 ?
    • De nouveaux Frameworks/API apportent une abstraction supplmentaire
      • Linq est une rvolution architecturale qui produit de manire native une abstraction de la couche daccs aux donnes (Linq2SQL, Linq2Entities, Linq2XML, etc )
    • Mais dautres techniques aussi
      • Les gnrateurs dynamique de codes (DynamicProxies, IL, )
      • Linjection de dpendance
      • LAOP
    Page Les outils voluent, le Design aussi Modifie la manire de penser n-tiers
  • 4. Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional, 2004.
  • 5. Avram, Abel et Marinescu, Floyd. Domain-Driven Design Quickly. Disponible gratuitement : http://www.infoq.com/minibooks/domain-driven-design-quickly .
  • 6. Page Larchitecture n-tiers traditionnelle Couche daccs aux donnes Couche dobjets du domaine Larchitecture n-tiers traditionnelle Couche de service Prsentation Partenaire Base de donnes Base de donnes BLL DAL Collections () XSL Donnes WebServices Domaine WebForms WinForms ASP.NET () Enterprise Services WebServices Remoting Threading Reflection Serialization Reflection XML ADO.NET Services
  • 7. Exemple de service traditionnel
    • namespace MyApplication.Services
    • {
    • [ServiceContract]
    • public interface IAccountService
    • {
    • [OperationContract]
    • public void Credit( Account account, double amount);
    • }
    • }
    Page public class AccountService { [OperationBehavior(TransactionRequired=true)] public void Credit( Account account, double amount) { 1) Vrification autorisation 2) Rcuprer DAL et raliser opration 3) commiter } } } Avec lmergence des Framework type Linq, lintrt dune couche DAL est de plus en plus discutable
  • 8. et le domaine
    • namespace MyApplication.Domain
    • {
    • public class Account
    • {
    • public Client Client {
    • get { return this.client; }
    • set {this.client = value ;}
    • }
    • public List EcrituresComptable {}
    • }
    public class EcritureComptable { public DateTime DateEcriture { get { return this.dateEcriture; } set {this.dateEcriture = value ;} public int MontantEcriture{} } } De simples structures ? Syndrome du modle anmique
  • 9. Avantages / Inconvnients
    • Le mtier est essentiellement bas sur les services
    • Inconvnients :
      • Duplication et copier/coller dans les couches de services
      • Difficile parfois de mettre en place des tests unitaires
      • Le code des services est finalement trs procdural, peu objet
      • La couche de service est pollue par linfrastructure (accs aux DAO, requtes Linq, etc ..)
    • Avantages :
      • Simple mettre en oeuvre, mature et respecte les dpendances binaires inter-couches (aucune assembly technique dployer ct client)
  • 10. Page Larchitecture n-tiers traditionnelle Couche Infrastructure Couche applicative Larchitecture DDD Couche du domaine Base de donnes Base de donnes Collections () XSL Repositories Prsentation Partenaire Domaine WebForms WinForms ASP.NET () Enterprise Services WebServices Remoting Threading Reflection Serialization Reflection XML ADO.NET Factories Services
  • 11. Page Lubiquitous Language et DSL Exemple Account Holder withdraws cash I want to withdraw cash from an ATM I can get money when the bank is closed Scenario 1 : Account has sufficient funds Given the account balance is $100 And the card is valid And the machine contains enough money When the Account Holder requests $20 Then the ATM should dispense $20 And the account balance should be $80 And the card should be returned Scenario 2 : Account has insufficient funds Given the account balance is $10 And the card is valid And the machine contains enough money When the Account Holder requests $20 The ATM should not dispense any money
    • Lubiquitous language est la base du DDD
      • Cest un language pseudo-technique comprhensible par la MOA et les dveloppeurs
      • Les verbes sont les mthodes, les sujets sont les objets
      • Tout changement dans lUL induit un changement dans le modle
    • La dmarche DDD est pilote par
      • Les tests (TDD)
      • Le refactoring
  • 12. Domain Driven Development
    • Multi-couches
      • Couche de prsentation
      • Couche Application (appele aussi couche de services)
        • Aucune logique mtier
        • Ne porte pas ltat des objets du domaine
        • Porte ltat dune tche applicative
      • La couche du domaine
        • Contient toute linformation du domaine
        • Ltat du domaine est ici
      • La couche dinfrastructure
        • Assure la communication entre les couches
        • Assure la persistence des objets mtier
        • Contient les librairies ou Framework externes
  • 13. Les Mots-cl de lunivers DDD
    • Focalis sur le domaine
    • Un langage unifi
    • Une architecture multi-couches
    • Entits et Value object
    • Services
    • Les modules
    • Agrgats (Aggregates)
    • Factories
    • Repositories
  • 14. Les agrgats
    • Plusieurs prceptes connus volent en clat
      • One to many, many to many, trop complexe !
      • Supprimer les relations inutiles, trop de relations tuent la relation
      • Rduire les multiplicits et direction (viter le bidirectionnel)
      • Laisser la base de donnes grer les oprations de Cascade et update/delete
    • Utiliser les agrgats ( aka aggregate)
      • Assure la gestion des relations entre objets
      • Un agrgat possde une entit comme lment racine
      • Seule la racine peut tre obtenue partir des requtes objets