InfOsaurus

Aller au contenu | Aller au menu | Aller à la recherche

mercredi 2 juin 2010

Persistez votre domaine avec Raven DB

 

RavensIl y a peu, je vous parlais d'une possible synergie entre les bases de données NoSQL de type document et les Agrégats de Domain Driven Design.

Entretemps est sortie la base NoSQL pour la plateforme .NET d'Ayende Rahien, Raven DB, et elle confirme ces suppositions. Voici un extrait de la documentation de la base au corbeau :

« When thinking about using Raven to persist entities, we need to consider the two previous points. The suggested approach is to follow the Aggregate pattern from the Domain Driven Design book. An Aggregate Root contains several entities and value types and controls all access to the objects contained in its boundaries. External references may only refer to the Aggregate Root, never to one of its child objects.
When you apply this sort of thinking to a document database, there is a natural and easy to follow correlation between an Aggregate Root (in DDD terms) and a document in Raven. An Aggregate Root, and all the objects that it holds, is a document in Raven. »

Avec Raven, les données sont stockées dans des documents JSON qui ressemblent à ça :


Document

Contrairement à une base relationnelle dans laquelle les données résident dans des tables fragmentées qu'on peut relier par l'intégrité référentielle, il est possible de stocker dans ce type de document tout un graphe d'objets complexes et typés. Les préconisations pour la conception de documents Raven sont donc à l'inverse de celles qui président au design d'une base de données relationnelle : il s'agit de regrouper au sein d'un seul document les objets formant un tout logique. Par exemple, un Livre regroupe à la fois un titre mais aussi les objets que sont son Auteur et sa Catégorie. Il se trouve que la notion d'Agrégat et de Racine d'Agrégat de DDD recoupe en tous points ce concept.

Un des bénéfices qu'on constate immédiatement avec Raven DB est l'élimination pure et simple de la couche de mapping objet-relationnel, parfois source de bien des complications. En effet avec Raven, plus de défaut d'impédance entre les objets de l'application et leur équivalent persisté relationnel. La couche persistance s'en trouve bien allégée.


Exemple en C#

Comme un bon exemple vaut tous les discours, voici comment on peut implémenter un Entrepôt avec Raven et son client C# natif :


   1:      public class Livre
   2:      {
   3:          public string Id { get; set; }
   4:          public Auteur Auteur { get; set; }
   5:          public string Titre { get; set; }
   6:          public Categorie Categorie { get; set; }
   7:      }


   1:      public class EntrepotLivres
   2:      {
   3:          public EntrepotLivres(IDocumentSession documentSession)
   4:          {
   5:              session = documentSession;
   6:          }
   7:   
   8:          public void AjouterLivre(Livre livre)
   9:          {
  10:              session.Store(livre);
  11:              session.SaveChanges();
  12:          }
  13:   
  14:          public void SupprimerLivre(Livre livre)
  15:          {
  16:              session.Delete(livre);
  17:              session.SaveChanges();
  18:          }
  19:   
  20:          public Livre GetLivreParId(string id)
  21:          {
  22:              return session.Load<Livre>(id);
  23:          }
  24:   
  25:          private IDocumentSession session;
  26:      }


   1:  class Program
   2:  {
   3:      static void Main(string[] args)
   4:      {
   5:          var documentStore = new DocumentStore { Url = "http://localhost:8080" };
   6:          documentStore.Initialize();
   7:   
   8:          using (var session = documentStore.OpenSession())
   9:          {
  10:              EntrepotLivres entrepotLivres = new EntrepotLivres(session);
  11:              ...
  12:          }
  13:      }
  14:  }

Pas de fichier de mapping à gérer à côté de ça, l'entité Livre et tout ce qu'elle contient se persistera de façon immédiate... Simple, non ?

On remarque qu'on manipule une Session Raven. Il s'agit d'une implémentation du pattern Unit of Work assez similaire à ce qu'on trouve dans des frameworks d'ORM comme NHibernate. En fait, bon nombre de concepts et dénominations dans l'API client C# de Raven sont directement issus de NHibernate.


Index et requêtes

Pour l'instant, notre Entrepôt ne fait qu'ajouter des entités, les supprimer et les hydrater à partir de leur ID, ce qui se fait nativement avec Raven. Pour exécuter des requêtes plus complexes sur nos documents, il faut passer par des index. Les index sont des vues stockées sur disque semblables aux vues matérialisées des SGBDR. Ils sont taillés pour un type de recherche particulier.

Voici comment on définit en C# un index qui porte sur les catégories des livres :


   1:          documentStore.DatabaseCommands.PutIndex("LivresParCategorie", 
   2:              new IndexDefinition<Livre>
   3:              {
   4:                  Map = livres => from livre in livres
   5:                                  select new { livre.Categorie }
   6:              });

Cet index ne doit être créé qu'une fois, il peut aussi être défini via l'interface d'administration de Raven en utilisant la même syntaxe.

On peut maintenant ajouter une méthode à notre entrepôt qui retourne tous les livres d'une catégorie. Elle effectue une requête LuceneQuery sur l'index précédemment défini :


   1:          public IList<Livre> GetLivresParCategorie(Categorie categorie)
   2:          {
   3:              return session.LuceneQuery<Livre>("LivresParCategorie")
   4:                  .Where(l => l.Categorie == categorie)
   5:                  .ToList();
   6:          }

Il existe une autre technique d'indexation plus sophistiquée, map/reduce, dont je parlerai peut-être dans un autre billet.


Raven DB

Impressions


Ce que j'aime dans Raven DB :

  • Simplicité de persistance des objets et affranchissement complet de la couche d'ORM.
  • Les données sont accessibles sous forme RESTful (chaque document dispose d'une URL) et lisible par un humain.
  • Sans doute bien plus facilement scalable qu'un SGBDR du fait de la nature atomique et autonome d'un document.
  • API .NET et requêtage sur les indexes en Linq.
  • Raven se marie bien avec DDD et une partie de l'effort de design de la base est déjà fait si on a découpé ses Agrégats.

Ce qui me plait moins :

  • Pour exploiter pleinement Raven en termes de performances, il faut idéalement ramener un seul document de la base et que celui-ci contienne tout ce dont on a besoin. Cela peut mener à une tendance à calquer les documents sur les IHM.
  • Raven DB a peut-être un petit impact sur la persistance ignorance de notre domaine. Il semble qu'une entité qui fait référence à la racine d'un autre agrégat (donc située dans un autre document, en termes Raven) ne peut pas avoir une référence directe à cet objet mais est obligé de contenir son ID à la place. Dans notre exemple, l'Auteur d'un Livre est un objet entièrement contenu dans l'agrégat Livre parce qu'on ne stocke que son nom et prénom. Mais si l'Auteur devait faire l'objet d'un agrégat séparé à lui (par exemple si l'auteur est un Utilisateur du système), le Livre devrait alors contenir la clé de l'Auteur et plus l'Auteur lui même. Sachant que les IDs natifs de Raven sont très typiques ("auteurs/465" par exemple), on se retrouve avec une trace de Raven dans le graphe d'objets du domaine, et aussi la nécessité de passer par un entrepôt pour réhydrater l'objet dont on n'a que la clé.

Les doutes à lever à l'avenir :

  • Les performances. Ayende a publié des mesures de perfs prometteuses mais il va falloir qu'elles soient confirmées sur des projets à plus grande échelle. En particulier, il serait intéressant de voir comment le système de concurrence optimiste de Raven se comporte dans un contexte transactionnel intensif.
  • L'adoption. Je pense que les bases NoSQL ne survivront pas sans un écosystème solide à la fois en termes de communauté et d'outillage disponible. Si on ne peut pas faire avec les bases non relationnelles tout ce qu'on fait avec les SGBDR (monitoring, tuning, reporting, analyse de données...), elles resteront une bonne idée sur le papier mais un choix pauvre sur le terrain.

vendredi 5 mars 2010

Règlement de comptes à Données Corral

Il va y avoir du sport

Derrière le jeu de mots vaseux de ce titre se cache une réalité beaucoup moins fun. Celle de la guerre que se livrent, depuis quelques temps déjà, les partisans d'une approche des bases de données novatrice et iconoclaste et les défenseurs de la tradition des SGBD relationnels.

Si vous suivez l'actualité du monde du développement, vous avez déjà compris de quoi je veux parler. Il ne vous a pas échappé que ces derniers temps, l'hégémonie des systèmes relationnels sur le marché des bases de données a été quelque peu chahutée : en 2009 sont apparues un certain nombre de bases regroupées sous le nom parapluie de "NoSQL". Ces systèmes (CouchDB, Big Table de Google, Project Voldemort...) sont des key-value stores, des document stores ou des bases fondées sur les graphes qui ont en commun de partir d'un constat de lourdeur du relationnel, du langage SQL et de ses jointures. Elles se veulent plus simples d'approche, plus scalable pour de gros volumes de données, plus adaptées au web et moins sclérosées par les schémas de données.


La rébellion gagne des voix

Il est intéressant de voir qu'en ce début d'année, il y a un regain de tension dans le débat qui oppose les deux visions et que celui-ci s'est invité chez les développeurs .NET. Plus particulièrement, deux acteurs importants de la communauté et qui n'ont pas a priori d'intérêt particulier à soutenir les bases NoSQL, ont pris position pour les défendre.

Le premier est Ayende Rahien, contributeur du projet NHibernate et créateur entre autres du framework d'isolation RhinoMocks. Dans un article nommé Slaying Relational Dragons, il remet en cause l'hégémonie des SGBDR et cite une session de support client à l'issue de laquelle il a recommandé de ne pas utiliser de base relationnelle. S'en suit un exemple de type d'application pour laquelle selon lui, il est tout à fait justifié d'opter pour un document store du style CouchDB. Plus étonnant, Ayende a également démarré un projet de base document, Rhino DivanDB, alors même qu'une grande partie de son travail des dernières années a été dévoué indirectement aux bases relationnelles par le biais d'NHibernate.

Une autre chose a piqué ma curiosité dans le billet d'Ayende : pour décrire les grappes de données pêchées dans une base NoSQL, il utilise le terme d'Agrégats. Oui, c'est à peu près la même notion d'Agrégat que dans Domain Driven Design. Visuellement, cela peut donner ceci (2 racines d'agrégat Book en l'occurrence) :

Agrégats

Si on cherche un peu, on s'aperçoit aussi que des frameworks DDD comme Jdon prévoient d'entrée l'utilisation d'une base NoSQL pour la persistance. Y aurait-il une synergie entre DDD et NoSQL dans la forme sous laquelle les entités sont appréhendées ? Intéressant, à creuser en tout cas.

Notre deuxième homme est Greg Young, très impliqué dans DDD justement, et qui a popularisé l'approche Command-Query Separation. Greg a comparé dans un billet récent l'utilisation d'un ORM au fait d'embrasser sa soeur (expression américaine désignant une action dénuée d'intérêt)... Pour lui, nous devrions plus souvent nous arrêter et nous demander si le choix d'un ORM couplé à un modèle de données relationnel pour notre projet, est bien justifié. Plutôt que de faire de l'ORM + SGBDR le choix par défaut, pourquoi ne pas envisager une base objet ou une base document à la place ? Dans certains cas, c'est beaucoup plus adapté au contexte et ça évite les problèmes de décalage d'impédance entre l'application objet et le modèle de données.


L'Empire contre-attaque

Bien sûr, les défenseurs des SGBD relationnels ont tôt fait de réagir. Un des plus virulents dans la contre-offensive a certainement été Frans Bouma, curieusement acteur de la scène ORM lui aussi (avec LLBLGen). Dans des commentaires et sur son blog, il avance trois arguments principaux pour contrer les enthousiastes du NoSQL :

  • Les cas évoqués par Ayende sont des anti-pattern, on essaie de créer un modèle de données qui est directement calqué sur la mise en forme d'un écran de l'application, ce qui est une mauvaise pratique.
  • Un modèle de données a pour vocation de représenter la réalité, et pas juste de refléter des entités utilisées dans une application (on retrouve un peu ici l'approche bottom-up vs l'approche top-down). Pourquoi ? Parce que dans un contexte d'entreprise, de multiples logiciels accèdent aux mêmes données et c'est de plus en plus vrai au fil du temps. Il faut donc un modèle qui représente parfaitement le métier et en est le garant quelle que soit l'application qui y puisera.
  • Les bases relationnelles existent depuis plusieurs dizaines d'années, elles sont fondées sur une théorie solide et ont fait l'objet d'innombrables recherches, ce qui en fait les outils incontournables et aboutis qu'on connait aujourd'hui. Toute concurrence est donc pour l'instant anecdotique.


Verdict

Conceptuellement, on voit bien le clivage entre les bases de type document store qui recèlent le strict nécessaire permettant à une application de fonctionner (le tout taillé sur mesure pour elle seule : une sorte de YAGNI de la donnée), et un modèle relationnel qui essaie de capturer la réalité de manière parfaite pour disposer d'une clé qui déverrouillera tous les situations à venir.

Sans prendre parti pour un camp ou l'autre, j'ai peur qu'à l'heure actuelle les bases NoSQL manquent de maturité face aux mastodontes relationnels. Mais elles restent une alternative à explorer et à mon avis, elles n'ont pas dit leur dernier mot. La guerre est loin d'être finie.

dimanche 6 décembre 2009

DDD Vite Fait, notions avancées

DDD Vite Fait Partie 2

Comme promis, voici la deuxième partie de la traduction de DDD Quickly : DDD Vite Fait, partie 2, notions avancées.

On y retrouve des techniques pour mettre en oeuvre DDD sur de gros projets impliquant plusieurs équipes, mais aussi pour refactorer un domaine et gérer sa croissance, notamment à travers la distillation et l'identification d'un Coeur de Domaine.

Bonne lecture ;)

(Mise à jour) : et voici le fichier complet avec les deux parties.

mercredi 14 octobre 2009

DDD Vite Fait, les fondamentaux de Domain Driven Design

DDD Vite Fait

Dans mon précédent billet, j'évoquais l'importance à mes yeux de l'approche collaborative du développement logiciel qu'apporte Domain Driven Design et je vous parlais d'un travail en cours sur DDD.

Et bien le voici : DDD Vite Fait, première partie - les fondamentaux de DDD.

Ce livre (en version originale DDD Quickly, par A. Avram et F. Marinescu) présente tous les concepts et patterns qui forment la base de Domain Driven Design. Le texte est voulu comme une courte introduction - 54 pages tout de même ! - avec comme but avoué l'hégémonie planétaire de DDD de diffuser la vision initiée par l'auteur Eric Evans et faire (re)découvrir Domain Driven Design, approche de développement logiciel parfois mal connue en France.

Vous pouvez télécharger le PDF de la version française ici ou sur le site DDDFrance.

Un grand merci à Floyd Marinescu pour m'avoir autorisé à traduire son ouvrage, et rendez-vous dans quelques semaines pour découvrir la deuxième partie : DDD, notions avancées...

jeudi 1 octobre 2009

Smells DDD, quand votre domaine sent des pieds

Smell

En ce moment, je me replonge dans Domain Driven Design, l'approche du développement logiciel orientée domaine initiée par Eric Evans. Il m'est subitement apparu une chose que je ne m'étais jamais représentée auparavant, certainement parce que j'avais abordé le sujet avant tout par son aspect technique : le plus important à mon avis dans DDD, ce ne sont pas les patterns, c'est la philosophie de la modélisation collaborative du domaine.

Comprenez-moi bien, j'estime que les design patterns évoqués dans DDD sont brillants, ce sont des guides précieux pour développer un code du domaine clair, maintenable et faiblement couplé. Mais pour moi, l'essence de DDD ne réside pas là. Elle réside dans la collaboration étroite entre experts métiers, concepteurs et développeurs pour construire un modèle du domaine qui reflète la réalité et permet de résoudre de vraies problématiques métier. Elle réside dans la constitution d'un langage commun qui, en plus de faciliter la compréhension du métier par les personnes techniques, instaure dialogue et confiance au sein de l'équipe projet. Car je pense que c'est cela qui, au final, permet de faire du bon logiciel.

Je me suis sans doute heurté à ce constat car ce n'est pas du tout le cas dans l'organisation dans laquelle je travaille actuellement. Ca serait même plutôt le contraire. La forme de communication privilégiée est le fichier Word de besoin, de recette ou le ticket d'outil de gestion de bugs. Les conversations téléphoniques sont rares et ont souvent lieu en famille, entre développeurs ou entre experts métier. Sans parler de vraies rencontres entre développement et métier, inexistantes. Une méfiance d'origine floue entre les deux camps a installé une guéguerre perpétuelle MOE/MOA, les uns accusant les autres d'en demander toujours trop et de changer sans cesse de besoin ; les seconds soupçonnant les premiers d'être des tire-au-flanc. Du coup, l'idée de base chez la MOE est de se conformer à la virgule près aux documents, tels des actes notariaux, et chez la MOA d'en fourrer le plus possible dans lesdits documents. Bien sûr, c'est la connaissance du domaine qui en pâtit, tant l'incompréhension est grande. Il est même surprenant de voir que des développeurs avec plusieurs années dans l'organisation n'ont qu'une vision parcellaire et approximative du métier. Au final, le résultat se ressent dans la qualité du logiciel.

D'ailleurs - et ça ne s'applique pas seulement à mon exemple - de tels problèmes refont souvent surface sous la forme de code smells qu'on pourrait appeler Domain smells. Je me suis amusé à en recenser quelques-uns :

  • Domaine fantôme : ça peut paraître abérrent, mais il n'y a pas de couche domaine dans le projet dont je parle, en partie à cause de la technologie employée. Le métier est fondu dans la masse du reste du code. Il va sans dire qu'une couche domaine séparée est indispensable, pour toutes les raisons de découplage, de lisibilité... qu'on peut imaginer.
  • Domaine râpé : On constate aussi parfois que des bouts de domaine sont saupoudrés dans des couches différentes, le plus dur étant de ne pas être tenté d'en mettre dans la couche présentation. Même si ça peut être justifié, il vaut mieux pour la maintenabilité de l'application conserver au même endroit tous les éléments liés au domaine.
  • Domaine indéchiffrable : un des principes de DDD est que le code du domaine doit être clair et compréhensible, et donner tout de suite une vision d'ensemble à celui qui y jette un oeil. Malheureusement ce n'est pas toujours le cas, souvent à cause d'une représentation brouillonne du domaine dans le code dûe à un manque de dialogue avec les experts métier. De plus il est facile de se perdre en créant toujours plus de helpers, de services et autres gestionnaires qui embrouillent la compréhension du domaine.
  • Abus de notion : qui n'a jamais été confronté au mot-valise du domaine, à la notion métier un peu floue qui se retrouve toutes les trois lignes de code dans chaque module de l'application ? Comme si un développeur avait trouvé que le mot sonnait bien et décidé de l'utiliser aussi fréquemment que possible. C'est souvent le signe d'une modélisation pas assez en profondeur, d'un concept du domaine qui recouvre trop d'aspects et devrait sans doute être subdivisé.
  • Frères jumeaux : parfois c'est l'inverse, deux mots différents sont employés à travers l'application pour recouvrir la même notion métier. Cela peut mener à penser qu'il s'agit de deux choses différentes, ce qui est source de confusion. Convenir d'un seul terme précis et bien identifié permettra d'éviter les malentendus.
  • Déphasage de concept : ce smell se fait sentir lorsqu'on interroge un expert métier sur une notion présente dans le code du domaine, et qu'on s'aperçoit qu'elle est en total décalage avec la réalité, même si l'application semble se comporter correctement pour l'utilisateur. Il peut s'agir d'une mauvaise interprétation ou d'une supposition hasardeuse de la part d'un développeur. En tout cas, le code est à reprendre et la communication est à revoir.

Je vois d'ici certains dire "C'est bien beau, mais les experts métier ne sont pas souvent disponibles et une communication écrite restreinte est mieux que pas de communication du tout." Bien sûr, mais après tout, n'est-ce pas dans l'intérêt de la personne métier d'avoir une collaboration aussi efficace que possible avec le développeur qui réalisera l'application pour lui ? N'est-ce pas primordial de s'assurer qu'il est au diapason de la réalité du domaine ?

Même si l'expert métier ne peut pas se rendre souvent disponible, il devrait l'être autant que faire se peut. Une solution au problème pourrait être de timeboxer les scéances de conception collaborative. Parfois, un dialogue d'une demi-heure bien cadré et sans perturbation peut être plus efficace qu'une réunion décousue de deux heures, qui aura pourtant demandé plus de disponibilité à l'expert du domaine...