insideIT.fr : le blog des architectes IT de SFEIR

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

mardi 16 juin 2009

Domain Driven Design : Eric Evans à l’EPITA le 15 Juin 2009

Le Paris JUG a fait très fort en réunissant plus d’une centaine de personnes à l’EPITA : bien que la conférence ait été annoncée quelques jours à l’avance et que le lieu de rendez-vous ait changé, c’était dans une salle presque comble que nous nous retrouvions hier soir.

La popularité montante du DDD mais aussi le networking y sont probablement pour beaucoup. C’était donc Eric Evans en personne qui a présenté sa session «DDD: putting the model to work» que vous pouvez suivre sur InfoQ Lors de cette session, Eric définit les termes «domain» et «model» :

Domaine : Ensemble de connaissances, d’influences ou d’activités.

Modèle : Ensemble d’abstractions qui décrivent des aspects que l’on a choisi dans un domaine. Le modèle est destiné à résoudre des problèmes liés au domaine qu’il représente.

Eric insiste alors sur le fait qu’un modèle ne doit pas tenter de résoudre tous les problèmes mais doit au contraire être restraint à des scénarios spécifiques. Il cite en exemple une vieille carte de la chine qui était utile à l’époque mais dans le contexte actuel où l’export est au coeur de l’économie chinoise, elle ne répond plus aux nouveaux besoins liés à l’ouverture de la Chine. De même l’exemple du planisphère montre qu’un modèle a tendance à s’éloigner de la réalité.

Le domaine du transport de conteneurs qui est tiré du livre «Domain-Driven Design» est intéressant car un modèle qui marchait bien pour les réservations et le calcul d’itinéraires (un itinéraire est composé de n étapes) n’a pas de sens si on tente de l’appliquer à un contexte d’optimisation des transports (il faut alors définir une structure de graphe).

Il y a toujours plusieurs modèles pour un domaine : il est nécessaire alors de bien délimiter les contextes. Le contexte est un cadre autour d’un mot ou d’une affirmation et qui va déterminer le sens de ce dernier. Un contexte délimité va alors limiter le champ d’application d’un modèle et par conséquent le simplifier et le rendre utilisable.

Enfin le DDD n’est pas toujours une solution appropriée car elle nécessite un dialogue avec les experts du domaine pour réaliser un modèle. Ce processus doit de plus suivre une approche itérative car on est toujours amené à faire du refactoring. Ce dialogue nécessite également de définir un langage commun (Ubiquitous language). Le modèle reprend alors les termes définis par ce langage et reste synchronisé avec ce dernier (implique les refactorings).

Il existe des frameworks encore au stade expérimental qui permettent de faciliter cette démarche. Qi4J (prononcer tchi-for-j) a été mentionné, il se base sur les motifs définis dans le livre d’Érice Evans. Son concepteur fait une comparaison avec un exemple DDD standard dans cette vidéo (Oredev 2008). C’est très prometteur !

Ont également été cités les BRMS, les langages fonctionnels et les DSL qui sont bénéfique à une approche DDD notamment par leur expressivité.

Et aussi dans la catégorie «considérations métaphysiques», pourquoi le terme «domain» plutôt que «business», sachant que l’on utilise souvent le terme «métier» en Français. Selon Éric on ne parle pas toujours d’un métier en DDD. À méditer :)...

Pour en savoir un peu plus, le livre d’Éric «Domain-Driven Design» semble être la référence. Notez également qu’Antonio Goncalves sera au Monde en Tique le 20 Juin pour dédicacer son livre sur Java EE 6.

vendredi 27 juin 2008

La réponse de Microsoft au Google App Engine

ssds_googleAppengine 

Depuis le Mix08, on connaît les SSDS ou SQL Server Data Services de Microsoft. Evolutifs à la demande (On-Demand Scalability), offrant un SLA (Service Level Agreement) de haut niveau (haute disponibilité, haute performance, protection contre la perte de données, sécurité) et résolument orientés Agilité.

Cela pourrait paraître une réponse à Amazon et son SimpleDB. Mais ce serait ignorer une vision et n'y distinguer qu'une innovation.

Et ce serait surtout se tromper de cible. Le concurrent n'est pas Amazon, qui convertit une erreur d'estimation de volumétrie de ses serveurs en innovation marketing (très ingénieuse il est vrai, mais au business modèle qui laisse perplexe). La ligne de mire est encore et toujours Google dont la montée en puissance a de quoi faire trembler Redmond. A l'heure du cloud computing, Google a comme un coup d'avance avec son Google App Engine et la capacité de déposer des applications simples directement sur la plateforme Google.

Les Windows Live Services présentent plus ou moins une réponse aux Google Apps. Et Microsoft ne proposerait rien face au Google App Engine ?

La stratégie s+s, Software + Service, propose d'attaquer des données hébergées sur un data-center (SSDS) à partir d'un logiciel client. Ne peut-on imaginer la possibilité de voir au côté de ces services de données, des conteneurs d'applications, proposés sur le même principe ? Non content d'avoir porté vos données sur ces nuages de serveurs (par définition toujours à la dimension désirée), vous pourriez envisager de déployer sans effort des applications web par un simple upload de code. Et celles-ci bénéficieraient des même caractéristiques citées au début de ce billet : évolutives, sous SLA, Agiles.

Alors après "Your Data, Any Place, Any Time" aura-t-on le "Your Applications, Any Place, Any Time" ? C'est plus que probable.

On attend donc avec impatience le prochain grand événement de la firme, le Microsoft PDC 2008 (octobre) où sera vraisemblablement fait une annonce à ce sujet.

mercredi 21 mai 2008

Les RIA en question

ria-venn-diagram_small On peut se demander souvent si ce sont les exigences grandissantes des utilisateurs qui dictent les évolutions des technologies de l'information. On peut se dire qu'à l'inverse ces mêmes évolutions rendent les utilisateurs plus exigeants en leur offrant toujours plus de possibilités et une meilleur qualité d'interface.

Il y a là comme une addiction toujours plus forte à la nouveauté pour elle même, des effets de mode comme un peu partout, une précarité, une volatilité comme nulle part ailleurs.

Le terme de RIA lui même existe depuis longtemps maintenant mais fait plus que jamais l'objet d'un débat acharné. Car au fond, qu'est-ce qu'une RIA.

Adobe en réclame la paternité depuis le départ, cherchant sans doute à créer dans l'esprit des gens l'amalgame avec sa technologie Flash/Flex/AIR (joli anagramme). Microsoft répond de son côté en jouant sur les mots, par sa "Rich Interactive Application", tentant de donner un coup de vieux à son ennemi de toujours et mise tout sur Silverlight/WPF. Pas mal d'autres acteurs tentent de tirer les marrons du feu avec plus ou moins de bonheur.

Ce terme de RIA fait sourire ou rêver. Les sceptiques croient qu'on essaye encore de leur vendre un vieux concept habillé de neuf, comme le boucher indélicat qui fait de la "retape". D'autres, y voient un horizon d'opportunités technologiques et de satisfaction client mêlés. Autant dire qu'en moyenne les premiers sont des utilisateurs, les seconds des programmeurs. Mais au fond que sont réellement les RIA ? Chacun y va de sa définition, de son exemple imparable, de son expérience propre mais aussi de ses rêves. Et finalement personne n'est vraiment d'accord sur le terme.

Pourtant la définition d'un mot ou d'une expression est quelque chose de primordial. Elle induit son utilisation. Bien entendu, elle peut évoluer dans le temps. Elle va s'enrichir, gagner ou perdre en sens. Mais elle forme la pensée, offre le concept. Et là, la technologie a apporté avec sa fébrilité un fait nouveau. Les mots ont avec elle un sens mouvant, instable qui va au gré des grands acteurs du marché. Pas d'académicien ici pour nous rappeler les règles d'usage. Les définitions ne sont pas dans des dictionnaires mais dans des brochures. Les mots sont des marques. Les sigles des bannières. Il faut qu'on dise "la RIA" c'est untel. Le fantasme du monopole n'est jamais loin. Wikipedia noie le poisson dans un flot de références et de liens, le tout plutôt orienté. Les articles sur le sujet sont pléthore et tous signés. La propagande est en marche. L'information y perd un peu.

Finalement, c'est un peu comme pour le terme Ajax, on en faisait bien avant de le voir apparaître. Mais quand le terme est sorti, chacun a voulu le prendre pour lui. C'est un peu aussi comme les standards. Chacun fait pression sur le standard pour le faire pencher vers soi. Tout le monde tourne autour, tente de faire croire qu'il en est le dépositaire et au final, personne ne le suit vraiment. Les standards ont pour objectif l'unité, la concordance. Ils servent surtout d'excuses à des guerres interminables.

En tout état de cause, le débat n'est pas prêt d'être clos. Espérons juste qu'il ne reste pas cloisonné dans une guerre marketing où le gagnant d'un jour est celui qui a le plus investi et pas dans la recherche mais dans la pub. Et gageons qu'il ne rende pas toujours plus flou un concept déjà pas très clair pour la plurpart d'entre nous.

lundi 11 février 2008

[TechDays 2008 - J1] Domain Driven Design par Sami Jaber

Après une rapide présentation de la 4ème édition du symposium DNG 2008 qui se déroule aujourd'hui, Sami a tenté de nous présenter le "Domain Driven Design" en une petite heure. Le DDD, pour faire court, est un design qui est apparu pour la première fois en 2003 sous la plume d'Eric Evans. Pour ceux qui par paresse ou manque de temps ne peuvent pas lire les 500 pages et quelques du livre d'Eric Evans, InfoQ en a résumé les principales lignes : DDD-quickly

Résumé de la présentation

Point de départ : de nouvelles technos comme Link modifient la manière de penser l'architecture en couches.

Architecture n-tiers traditionnelle

Les différentes couches sont Présentation, Services (use case fonctionnel), Domaine (objets métier) et Accès aux données. Les traitements métier sont concentrés dans la couche service. Par conséquent, le code est souvent procédural, peu objet, et dur à tester. Ceci pose également des problèmes de redondance et donc de maintenance du code.

Ceci se traduit par des méthodes de manipulation sans état, statiques, et des objets qui ne sont qu'une liste de champs avec getters setters. Les méthodes qui manipulent logiquement les données internes d'un objet ne se retrouvent pas dans l'objet mais dans une classe à part qui contient les méthodes statiques.

Une logique objet voudrait que les objets contiennent eux-mêmes les méthodes capables de manipuler leurs variables d'instances.

Domain Driven Design

Les différentes couches sont Présentation, Domaine, Application et Infrastructure. Le principe du DDD est de faire graviter la logique métier autour de la couche Domaine, autour des objets. Les objets contiennent le code métier, et font eux-mêmes les appels nécessaires au déroulement du service (appel à la couche service, appel à la base via la couche accès aux données, etc.)

En conséquence, ils constituent le point d'entrée du service et orchestrent l'interaction entre les couches. De fait, on ne peut plus faire simplement de l'injection de dépendance dans les objets, puisque cela suppose une manipulation des objets depuis une autre couche. Le "remplissage" des objets, leur instanciation, va donc être faite soit par de simples appels aux constructeurs, soit via des "Factory", appelées par les objets eux-mêmes.

Le mécanisme de manipulation des objets peut s'avérer complexe si l'agrégat d'objets est gros, si le nombre d'objets manipulés est important. Pour gérer cette manipulation, on va considérer cet agrégat d'objet comme une entité munie d'un objet racine, point d'entrée de l'agrégat.

Il peut s'avérer lourd de procéder à une instanciation et une injection de dépendances sur toute une arborescence d'objets lorsque le seul but est de récupérer des valeurs en base liées à ces objets. C'est là qu'interviennent les Value Objects, objets immuables qui autorisent simplement l'accès à l'information contenue dans ces objets en base.

Autre conséquence du DDD : la couche d'accès aux données classique disparaît : la couche des services n'est plus là pour appeler la couche accès : les données sont donc remontées autrement, via les "Repositories". Les repositories permettent d'effectuer les opérations de recherche en base.