Introduction au Domain Driven Design

Slide 1: Le Domain Driven Design Une conception pilotée par le domaine pour l’entreprise Sami Jaber (webmaster du site DotNetGuru.org et fondateur de DNG-Consulting) Page  1

Slide 2: Le Symposium DNG  4 ème édition, plus de 2000 inscriptions Présence de Bill Gates en 2005 Erik Meijer en 2008  Partenariat de longue date avec Microsoft (avec d’abord Marc Gardette et aujourd’hui François Merand)  Objectifs Développer des sujets d’entreprise Anticiper les évolutions des architectures de demain Prendre du recul sur le marketing des éditeurs  Le Symposium a contribué à : Démocratiser les architectures en couches Faire connaître le mapping O/R, l’AOP, SOA, les pratiques agiles…

Slide 3: Pourquoi encore parler d’architecture en 2008 ? Les outils évoluent, le Design aussi  De nouveaux Frameworks/API apportent une abstraction supplémentaire Linq est une révolution « architecturale » qui produit de manière native une abstraction de la couche d’accès aux données (Linq2SQL, Linq2Entities, Linq2XML, etc …)  Mais d’autres techniques aussi Les générateurs dynamique de codes (DynamicProxies, IL, …) L’injection de dépendance L’AOP Modifie la manière de penser n-tiers Page  3

Slide 4: Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional, 2004.

Slide 5: Avram, Abel et Marinescu, Floyd. Domain-Driven Design Quickly. Disponible gratuitement : http://www.infoq.com/minibooks/domain-driven-design-quickly.

Slide 6: L’architecture n-tiers « traditionnelle » Présentation Couche de Couche Couche BLL DAL service d’objets du domaine d’accès aux données Domaine Services Base de données Partenaire Données WebServices Base de données ASP.NET WinForms Remoting Serialization ADO.NET WebForms WebServices Reflection XML XSL Enterprise Services Threading Reflection (…) (…) Collections Page  6 L’architecture n-tiers traditionnelle

Slide 7: Exemple de service « traditionnel » namespace MyApplication.Services { [ServiceContract] public interface IAccountService { [OperationContract] public void Credit(Account account, double amount); } } public class AccountService { [OperationBehavior(TransactionRequired=true)] public void Credit(Account account, double amount) { 1) Vérification autorisation 2) Récupérer DAL et réaliser opération 3) commiter } } Avec l’émergence des Framework } type Linq, l’intérêt d’une couche DAL est de plus en plus discutable Page  7

Slide 8: … et le domaine namespace MyApplication.Domain { public class Account { De simples public Client Client { structures ? get { return this.client; } Syndrome du set {this.client = value;} modèle anémique } public List EcrituresComptable {} … } public class EcritureComptable { public DateTime DateEcriture { get { return this.dateEcriture; } set {this.dateEcriture = value;} public int MontantEcriture{} } }

Slide 9: Avantages / Inconvénients  Le métier est essentiellement basé sur les services  Inconvénients : Duplication et copier/coller dans les couches de services Difficile parfois de mettre en place des tests unitaires Le code des services est finalement très procédural, peu objet La couche de service est polluée par l’infrastructure (accès aux DAO, requêtes Linq, etc ..)  Avantages : Simple à mettre en oeuvre, mature et respecte les dépendances binaires inter-couches (aucune assembly technique à déployer côté client)

Slide 10: L’architecture DDD Couche du domaine Couche applicative Couche Infrastructure Présentation Repositories Services Base de données Partenaire Domaine Base de Factories données ASP.NET Remoting WinForms Serialization ADO.NET WebForms WebServices Reflection XML XSL Enterprise Services Threading Reflection (…) (…) Collections L’architecture n-tiers traditionnelle Page  10

Slide 11: L’ubiquitous Language et DSL  L’ubiquitous language est à Exemple Account Holder withdraws cash la base du DDD I want to withdraw cash from an ATM I can get money when the bank is closed C’est un language pseudo-technique Scenario 1: Account has sufficient funds compréhensible par la MOA et les Given the account balance is $100 And the card is valid développeurs And the machine contains enough money When the Account Holder requests $20 Les verbes sont les méthodes, les sujets Then the ATM should dispense $20 sont les objets And the account balance should be $80 And the card should be returned Tout changement dans l’UL induit un Scenario 2: Account has insufficient funds changement dans le modèle Given the account balance is $10 And the card is valid And the machine contains enough money  La démarche DDD est pilotée par When the Account Holder requests $20 The ATM should not dispense any money Les tests (TDD) Le refactoring Page 11

Slide 12: Domain Driven Development  Multi-couches Couche de présentation Couche Application (appelée aussi couche de services) - Aucune logique métier - Ne porte pas l’état des objets du domaine - Porte l’état d’une tâche applicative La couche du domaine - Contient toute l’information du domaine - L’état du domaine est ici La couche d’infrastructure - Assure la communication entre les couches - Assure la persistence des objets métier - Contient les librairies ou Framework externes

Slide 13: Les Mots-clé de l’univers DDD  Focalisé sur le domaine  Un langage unifié  Une architecture multi-couches  Entités et Value object  Services  Les modules  Agrégats (Aggregates)  Factories  Repositories

Slide 14: Les agrégats  Plusieurs préceptes connus volent en éclat One to many, many to many, trop complexe ! Supprimer les relations inutiles, trop de relations tuent la relation Réduire les multiplicités et direction (éviter le bidirectionnel) Laisser la base de données gérer les opérations de Cascade et update/delete  Utiliser les agrégats (aka aggregate) Assure la gestion des relations entre objets Un agrégat possède une entité comme élément racine Seule la racine peut être obtenue à partir des requêtes objets L’entité est responsable de maintenir les invariants (règles non liées à la modification de données)

Slide 15: Exemple d’agrégat  Fonctionnel : une facture est associée à un client Un client possède une adresse Une facture contient des lignes, associées à un produit Racines Page  15

Slide 16: Les Factories  La création d’un objet est parfois complexe, spécialement pour les agrégats Utiliser des factories Créer la racine de l’agrégat et l’ensemble des objets qui le contiennent Création atomique Attention à veiller à ne pas violer l’encapsulation  Possibilité d’utiliser l’ordre New() dans certains cas : Bénéfices : - Simplicité - Tous les attributs peuvent être passés au constructeur - Aucun besoin de changer d’implémentation

Slide 17: Et la couche de services ?  Certains concepts ne sont pas naturel à un domaine en particulier, exemple : Exporter au format CSV le contenu d’une facture Accéder à plusieurs comptes pour réaliser un transfert de fond  Tout ce qui n’est pas de l’ordre d’un traitement lié à un objet du domaine ou à un traitement lié à l’infrastructure  La couche du domaine s’appuie sur les services (l’inverse est aussi possible) Page  17

Slide 18: Les Value Objects  Utilisés lorsqu’il est important de maîtriser le contenu d’un objet et non son identité  Quand écrire un VO ? Lorsque le VO n’est pas une Entity ! Encore mieux si le VO est immuable (son contenu n’évolue pas) Pour les performances Pour l’intégrité des données (pas de risque de modification par erreur) Si les VO sont partageables, ils doivent être immuables Garder les VO “petits” et simples Un VO peut contenir des références vers d’autres VO ou des entités

Slide 19: Les repositories  Le DDD comme toute philosophie multi-couches ne couple pas l’infrastructure technique au modèle du domaine  Le repository encapsule la logique permettant d’obtenir des références d’objets Les méthodes doivent rester simples (généralement des recherches)  Une factory crée, un repository recherche. « A factory is pure domain, a repository communicates with the infrastructure » (E. Evans) Page  19

Slide 20: Exemple avec Linq public interface IOrderRepository : IRepository<Order> { Order FindWithId(string orderId); ICollection<Order> FindAllOrders(); ICollection<Order> FindAllValidOrders(); bool IsUniqueOrder(string orderId); bool IsValidOrder(string orderId); } public class OrderRepositoryImpl : IOrderRepository { ICollection FindAllValidOrders(string orderId); ICollection<Order> orders = Repository<Order> .FindAll(Where.Order.Id == orderId && Where.Order.Status == OrderStatus.ReadyToShip && Where.Order.Date >= DateTime.Today); return orders; }

Slide 21: Les DSL à la rescousse (exemple réalisé avec Boo)  Les DSL peuvent apporter énormément sur la partie « statique » du modèle architectural  La partie dynamique reste complexe à modéliser sans recourir au code Page  21

Slide 22: La big picture DDD Page  22

Slide 23: DDD, l’architecture idéale ?  Non. Le design idéal n’existe pas.  La force et le principal défaut du DDD est de s’appuyer sur le libre choix du concepteur On hésite souvent entre couche de service et couche du domaine Le lien entre couche du domaine et Repository (persistence) prête à discussion Patterns possédant les même défauts que ceux d’Active Record - granularité fine des services entraîne une granularité fine des requêtes SQL). Problème de N+1 (performances)  Mais la formalisation du fonctionnel par le domaine est un concept en devenir, encore peu exploité par les architecture n-tiers traditionnelles Page  23

Slide 24: La couche de présentation Un des enjeux majeurs de demain

Slide 25: La couche de présentation coûte cher  On estime en moyenne que la répartition budget/couches pour une application de gestion classique coûte : Couche d’accès aux données : 30 à 50 % Couche de services (règles de gestion) : 30 à 50 % Couche de présentation : 30 à 50 %  Les fourchettes s’expliquent par le type d’outils employées (générateurs de code DAL, O/R Mapping, générateur d’écrans, etc …)  Ces dernières années, énormément de progrès ont été fait pour augmenter la productivité de la couche d’accès aux données et la couche de service  Mais la couche de présentation reste à la traîne !

Slide 26: La couche de présentation coûte cher  Et pourtant, de nombreux progrès ont été réalisés sur la partie designer : Les éditeurs WYSIWYG (WPF Designer, WinForms Designer, ASP.NET Designer) Des Framework de composants plus riches (vectoriels, …)  Pourquoi une telle différence ? Encore trop de code pour réaliser le lien entre les interfaces graphiques et les objets du domaine Historiquement, .NET a toujours privilégié le lien interfaces graphiques vers bases de données (DataSet, DataAdapter, …)  Le Binding avec les objets est en plein essor - WPF et Adobe Flex sont les plus avancés dans ce domaine

Slide 27: Le trio gagnant  Data Binding + Validation + Converter  80% du code induit par la couche de présentation relève de : la validation des champs de surface (les contrôles référentiels et d’intégrité sont dans la couche de services) la conversion des formats (date, intervalles, textes spécifiques, …) la gestion des messages d’erreurs Page  27

Slide 28: Le binding  Le Binding peut être Uni ou Bi-directionnel Le bidirectionnel améliore la maintenabilité du code Bindé sur le détail d’une Facture Propriété : Id Ligne Facture Ligne Page  28

Slide 29: La validation et la conversion  La validation est opérée dès lors qu’une valeur convertie dans son format destination est considérée correcte  Il suffit d’annoter avec des custom Attributes le modèle du domaine pour disposer d’une puissance redoutable en terme de productivité

Slide 30: Ce type d’architecture existe-t-elle ?  Certaines parties existent déjà en tant que telles dans : WPF (Windows Presentation Foundation) Adobe Flex Windows Forms et Java Swing (Norme Beans Binding) avec un support moindre de l’autobinding (la possibilité de placer des Binding Path sur des widgets)  Les Framework Web sont plutôt à la traîne même s’ils intègrent tous des Framework de validation ou de binding (ASP.NET) L’apport d’AJAX permet de simuler des sortes de Master/Detail réactifs  Le développement d’un (mini) Framework est nécessaire

Slide 31: Conclusion  Le développement pilotée par le domaine ou centré sur le domaine est en plein essor  Dans l’univers .NET les outils sont prêts pour intégrer ce mode de développement WCF pour la partie services techniques (transaction, sécurité, montée en charge) Linq pour l’accès aux données WPF et WinForms pour l’autobinding  Jamais la productivité du développeur n’aura été autant au centre des préoccupations des éditeurs  Après le quick & dirty, voici venu le temps du clean RAD Page  31

Slide 32: Annexes Page  32

Slide 33: Sites et liens …  Validation Application Block (Patterns & Practices) http://blogs.msdn.com/tomholl/archive/2006/11/27/validation-a  Microsoft Data Access blog http://blogs.msdn.com/adonet  Domain Driven Design http://www.domaindrivendesign.org/  DotNetGuru.org (actualité, articles techniques, etc …) http://www.dotnetguru.org  DDD avec .NET (Livre Applying Domain-Driven Design) Jimmy Nilsson Page  33