Fabien Bézagu

Je vais essayer de décrire dans ce billet ce que je crois être un pattern. Il s'agit peut-être d'une fausse bonne idée ou le pattern existe peut-être déjà. Dans tous les cas, les retours seront grandement appréciés.

Lire la suite

Cette session était pour moi la plus mystérieuse de toute. Je n'avais, je le confesse, jamais entendu les termes ROA (Resource Oriented Architecture) et REST (Representational state transfer). Aurélien Pelletier nous a donc présenté cette architecture d'une manière tout à fait passionnante.

Aurélien nous a donc expliqué qu'une quatrième génération d'applications était en train d'émerger : après le mainframe, le client/serveur (ou client lourd), le client léger (Web classique), l'heure semble être au client riche. Le principe est d'utiliser, dans la mesure du possible, les possibilités du client sans systématiquement solliciter le serveur.

Les ressources, dans cette approche, sont au centre du problème et les URI ainsi que le protocole HTTP doivent être utilisés afin de mieux représenter la richesse de l'information recherchée. Ainsi, pour voir le détail d'un speaker DNG du symposium, on pourrait utiliser l'URI suivante :

http://dng.org/symposium/2008/speakers/aurelien
Accept: html

Cela aurait pour effet de nous renvoyer, via HTTP, une page html affichant les détails de cet intervenant.

Je me rend bien compte, en écrivant ce billet, que je suis incapable de résumer l'excellent exposé d'Aurélien. Cependant, j'ai bien senti tout l'intérêt de cette approche et y perçoit des possibilités extraordinaires. Cette vision du web et des applications me plaît beaucoup. De plus, je sens que l'association avec une approche DDD pourrait constituer une belle combinaison en mettant d'avantage les choses que les actions sur ces choses au centre du problème.

Je vais essayer, quand j'aurai un peu temps, de creuser le sujet. Encore bravo à Aurélien pour la session qui m'a le plus touché.

Quelques liens :

• Blog d'Aurélien Pelletier
• Site de Roy Fielding dont la thèse est à la base du REST
• Livre Restful Web Services
• Livre Services Web RESTful (la traduction française)

Pour cette session, le symposium DNG s'offrait la meilleure personne pour présenter son projet : son créateur. Erik Meijer est en effet le papa de Volta et sa présentation était particulièrement dynamique et amusante.

Je ne suis pas persuadé d'avoir saisi tous les tenants et les aboutissants de ce nouveau framework mais l'idée est séduisante : Volta, c'est mon neveu qui fait le sale boulot à ma place selon Erik Meijer lui-même.

En effet, Volta a l'air vraiment excitant car il permet, en rajoutant par exemple un attribut sur une classe, de spécifier si l'exécution des méthodes d'une classe doit avoir lieu dans le navigateur du client ou sur le serveur. Et le tout, en écrivant du C# (euh pardon, du VB, oui Erik, c'est moins verbeux ;-). On peut également rendre une méthode asynchrone, toujours en ajoutant un attribut. Cela laisse entrevoir des perspectives très intéressante en terme de facilité de développement et de découpage en tiers.

Je pense que le succès d'un tel framework sera assuré dès qu'il sera bien intégré à l'environnement de développement et donc, finalement, oublié.

Site de Volta : ici

Lors de la session d'ouverture, Sami Jaber nous a présenté Domain Driven Design (DDD). J'attendais cette session avec impatience car, comme mon lecteur assidu le sait, je fais tout mon possible pour mettre en avant cette approche au quotidien.

J'ai toujours admiré le travail et la qualité d'orateur de Sami. Lors du Symposium DNG 2005, j'avais trouvé sa présentation brillante et je l'avais senti passionné et convaincant. Mon sentiment est plutôt à l'opposé par rapport à sa session d'hier.

Je sais que c'est très prétentieux de ma part mais je pense qu'il est passé complètement à côté de ce sujet et je vais essayer d'expliquer pourquoi je pense cela.

• Une nouvelle architecture ? : il a voulu présenté DDD comme une nouvelle architecture d'application : ce n'est pas le cas. DDD est une approche, pas une énième façon de mettre les couches les unes sur les autres. Bien sûr, il est important de séparer ces couches mais le point important de DDD est d'avoir une couche séparée contenant tout le modèle du domaine.

• Les services : je crois qu'il s'agit de sa plus grosse erreur. Pour lui, le principe de DDD consiste juste à inverser la couche du domaine qui s'appuierait désormais sur les services. Non, non et non. Selon Evans, il existe trois types de services : les services d'application (interface avec l'utilisateur, export des fichiers...), les services du domaine (ceux qui répondent à un vrai problème métier : transfert de fonds bancaires...) et les services d'infrastructure (envoie de mail, communication réseau...). Ces trois types de services appartiennent chacun à leurs couches respectives : application, domaine et infrastructure. Les services du domaine ne doivent pas être mis en retrait ou en avant des entités et des objets valeur mais bien à côté, sans les séparer. Je crois que c'est ce genre d'erreur qui produit une question pertinente d'un auditeur à la fin : Mais le métier, il est dispersé partout ?!. C'est exactement le contraire que prône Eric Evans : recentrer le métier dans le modèle et communiquer avec l'expert du domaine sur ce cœur.

• Les repositories : là encore, comparer les repositories à des DAO est une erreur. Comme je l'esquissais déjà dans un précédent billet, la différence est plus profonde : les repositories doivent être vues comme des collections d'entités et pas comme des simples objets d'accès aux données. La persistance doit être considérée comme une incidence du cycle de vie des entités dépassant celui de la session utilisateur.

Au delà de ce que Sami a dit, c'est surtout ce qu'il n'a pas dit qui me gêne. Je sens bien qu'il n'adhère pas du tout à DDD (C'est pas moi qui le dit, c'est Eric Evans) et on perçoit une certaine pointe de fatalisme dans l'approche DDD (Je n'y adhère pas forcément mais je vous en parle car dans cinq ans vous aurez à faire face à cette approche). Il n'a pas, à mon humble avis, saisi la force de DDD qui réside dans cette volonté de "presser la connaissance" (crunching knowledge) pour en retirer un langage commun (ubiquitous language) qui va dès lors qu'il a été mis en évidence être utilisé conjointement par les développeurs et les experts du domaine pour réaliser le modèle. Ce langage n'est pas, comme il le dit, un jargon spécifique du projet mais bel et bien le langage métier qui permet enfin d'éviter les problèmes de traduction et d'incompréhension des deux mondes que sont la MOE et la MOA.

Dans une deuxième moitié de sa présentation, il a également voulu présenter une façon de binder les entités du modèle à l'interface utilisateur. L'approche est louable et j'avoue qu'il est séduisant de descendre les contraintes de validation au niveau du modèle. Je pense que cette idée va dans le bon sens. Cependant, le binding n'est pas la réponse à tout et il n'a pas évoqué possibilité de mettre en place un framework MVC pour faire la glue qu'il lui manque entre son IHM et le modèle. Dommage. Les entités du modèle ne sont pas forcément exposées aussi brutalement à une couche de présentation; la mise en place d'un couche applicative est parfois indispensable, ce qui, dans une approche du "tout bindé" est infaisable.

Ma conclusion est la suivante : si vous voulez réellement vous intéresser à DDD, suivez les liens suivants.

• www.DomainDrivenDesign.org, site de référence. Les livres intéressants sont présentés dans la section Book.
• Livre DDD Quickly dont Sami a parlé
• Groupe de discussion créé par Eric Evans sur Yahoo

Petit message personnel : Sami, si jamais tu passes par ce coin pommé du web, je tiens à m'excuser pour cette critique virulente que je souhaite constructive et t'invite à me laisser un petit commentaire.

Edit du 13/02/08 : Voici quelques retours sur la session :

• Compte-rendu par InsideIT
• Retour de Philippe PEURET

De retour sur Bordeaux après une journée bien chargée au Symposium DNG 2008, je vais essayer de faire un petit bilan de ce que j'y ai retenu.

Tout d'abord, en ce concerne l'organisation, je dois bien avouer ma déception. Le symposium a perdu son identité propre et les salles attribuées étaient bien souvent trop petites pour accueillir tout ceux qui voulaient assister aux sessions DNG. Je comprend qu'il puisse y avoir des avantages à être intégré à un événement comme les TechDays de Microsoft mais de l'intégration à l'absorption il n'y a qu'un pas qui risque d'être franchi si une telle collaboration se reproduit la prochaine fois. Evidemment, je souhaite une prochaine fois et c'est pourquoi je pense que le Symposium DNG doit exister comme évènement séparé.

Autre point sensible que je note : l'indépendance vis à vis de Microsoft. Cette indépendance a toujours été la pierre angulaire de la communauté DNG et c'est pour cela qu'on retrouve à ce genre d'évènement autant de développeurs Java qui ne veulent pas nécessairement entendre la bonne parole officielle de Microsoft. Je suis persuadé que cette liberté est toujours présente mais j'ai entendu plusieurs intervenants la mettre en avant : "Ne vous inquiétez pas, nous pouvons toujours dire ce que nous voulons !". Une vérité n'a pas à être rappelée sauf si elle est en danger.

Voilà mon sentiment et je souhaite longue vie à DNG et à son Symposium tout en me faisant du souci pour l'avenir. En attendant, je vais essayer d'écrire un billet par session DNG puisque j'ai eu la chance de ne pas être refoulé une seule fois ;-)

Edit du 18/02/08 : je rajoute la liste des billets déjà écrits.

• Domain Driven Design
• Volta
• Je n'écrirai pas de billet sur Entity Framework et Link car je partage l'avis de BodySplash sur le sujet
• ROA et le REST
• .NET et l'open source : à venir

Elle nous accompagnait dans notre vie depuis huit ans et elle est partie très vite. Trop vite.

Ajourd'hui, je suis très triste.

Sa vie, elle ressemblait à ça :