Le livre de Vaughn Vernon, Implementing Domain Driven Design s'attaque à un des secrets de polichinelle de la communauté du développement logiciel : il y a beaucoup plus de gens qui veulent faire du Domain Driven Design qu'il n'y en a qui comprennent comment l'utiliser. Vernon traite ce problème en guidant ses lecteurs à travers les principes de DDD, en illustrant l'importance de chacun d'eux et en montrant comment les mettre en œuvre de façon adéquate. En s'appuyant sur une grande variété de techniques pédagogiques comme des exemples de code, la présentation des règles de base, une étude de cas progressant tout au long du livre et la "bonne vieille logique du Cowboy", IDDD arrive à être suffisamment accessible pour que même les non-initiés se hissent à un excellent niveau de compréhension de DDD.
La logique du Cowboy LB : "Quand vous vous trouvez vraiment assoiffés, buvez toujours en amont du troupeau." Implemeting Domain Driven Design, p. 99
Tout au long de son livre, Vernon fait référence à une équipe de développement imaginaire en train d'apprendre et d'implémenter DDD. Dans chaque chapitre, l'équipe devient de plus en plus efficace dans l'application des différents concepts et ses discussions détaillant les avantages et les inconvénients de leurs découvertes permettent au lecteur de se sentir impliqué dans leurs décisions. Tout en itérant et en s'améliorant dans la conception, l'équipe démontre la réelle nécessité d'adopter le Refactoring comme mécanisme de compréhension du domaine sur lequel on travaille. Ce qui vous est proposé à travers cette étude de cas, c'est une illustration très détaillée du processus collaboratif au sein d'une démarche DDD et c'est de voir ce qu'il est possible d'expérimenter, sans avoir à prendre de risque.
Le spectre très large de DDD est une des barrières courantes à son adoption au sein d'une organisation. À cause de cela, les développeurs choisissent souvent d'éluder l'approche "big bang" et préfèrent n'introduire une nouvelle facette de DDD que lorsque le besoin devient vraiment évident au regard du domaine. Vernon admet cette approche fragmentée de DDD et, en s'appuyant sur son expérience et des exemples détaillés, il arrive à faire comprendre au lecteur les avantages que l'on peut espérer en adoptant sur le moment un nouveau concept et les inconvénients auxquels l'équipe ferait face si elle choisissait de l'implémenter plus tard. Cette façon de présenter les divers aspects de DDD permet au lecteur de prendre des décisions éclairées sur la façon de porter son propre domaine à maturation sans avoir à tâtonner outre mesure.
La logique du Cowboy LB : "Tu vois, J, quand un cowboy est trop vieux pour montrer le mauvais exemple, il se met à donner de bons conseils." Implementing Domain Driven Design, p. 457
"Implementing Domain Driven Design" contribue de façon significative à la littérature de la conception logicielle en général et de Domain Driven Design en particulier. Les exemples de Vernon sont clairs et utiles : ils sont abordables et font office de référence fiable. Ils donnent au lecteur la confiance et la connaissance nécessaires pour s'essayer à DDD pour ses propres besoins. Pour ajouter à sa pertinence et à son utilité, les pratiques décrites dans IDDD entrent en résonnance avec les travaux antérieurs dans le monde de DDD, tels que Domain Driven Design d'Eric Evans et Applying Domain Driven Design de Jimmy Nilsson et appuient les principes et pratiques de la conception orientée objet. "Implementing Domain Driven Design" constitue non seulement un apport bienvenu autant qu'important pour la littérature du DDD mais il aidera aussi tout développeur, d'où qu'il vienne, à améliorer ses compétences en matière de conception et de collaboration… même s'il n'en est pas à son premier rodéo.
InfoQ a pu joindre Vaughn Vernon pendant l'escale Européenne de son IDDD Tour pour une interview virtuelle, que voici :
InfoQ : Le travail d'Eric Evans sur Domain Driven Design est largement considéré comme l'étalon concernant la définition et la mise en œuvre de DDD. Votre livre sur Domain Driven Design sort presque une décennie après le "livre bleu" d'Evans. Pourquoi maintenant ?
Si vous faites un tour d'horizon, vous trouverez d'autres livres traitant de DDD d'une façon ou d'une autre. Par exemple, le livre de Jimmy Nilsson a suivi de peu celui d'Eric Evans. Je pense que Jimmy a été pertinent dans sa présentation et ses efforts ont grandement contribué à faire avancer la communauté .Net.
Mon livre est différent des autres en ce qu'il adopte une approche centrée sur les "études de cas". Il montre volontairement le genre d'erreurs qui sont faites très souvent avec DDD et, de là, il révèle comment corriger ces erreurs ou comment les éviter. Cette approche produit au moins deux effets.
D'abord, elle montre clairement au lecteur ce qu'il faut éviter en repérant à l'avance les écueils courants. Une des choses les plus difficiles à faire en tant que consultant est d'entrer dans un projet où tout le monde travaille dur mais se trouve en difficulté ou en échec et de mettre le doigt sur ce qui est mal fait. Une équipe a tendance à être naturellement rétive à toute aide parce que elle fait réellement corps avec ses idées, même si elle peut admettre que ses résultats pourraient être meilleurs.
Le fait que le livre mette en avant les problèmes qu'une autre équipe a rencontré aide le lecteur à abandonner toute posture défensive. Il peut aisément se placer dans la position de l'équipe en difficulté.
Le deuxième point, c'est que le livre fournit des directives claires pour implémenter DDD de la façon la plus sûre possible. En suivant ces directives, ces "règles de base", les équipes abordant DDD bénéficient des meilleurs conseils pour réussir. Cela ne veut pas dire que vous ne pourrez jamais réussir si vous décidez d'enfreindre une règle ou deux, seulement, les règles devraient être suivies jusqu'à ce que vous compreniez les compromis auxquels vous ferez face si vous faisiez ce choix.
Pourquoi maintenant ? Après avoir travaillé une décennie ou deux dans l'industrie du logiciel, qui ne conviendrait pas qu'il est grand temps pour tout le monde d'accorder une sérieuse attention à faire du développement logiciel un métier avec une expertise propre ? Bien sûr, certains feront la sourde oreille et le reste d'entre nous ne pourra qu'espérer ne pas se retrouver avec eux sur un projet. Si vraiment on se retrouve dans cette situation, ce dont on veut être sûr, c'est de savoir comment se protéger des dégâts, notamment en ayant recours aux pratiques saines proposées par DDD. C'est donc vraiment le moment, je dirais.
InfoQ : Implémenter DDD peut prendre du temps dans une organisation. Quels genres de bénéfices, dont on pourrait profiter au fur et à mesure, de façon incrémentale, peut-on attendre d'une telle initiative ?
Je pense qu'une équipe désirant aller pas à pas, de façon incrémentale, pour améliorer sa conception peut envisager les choses selon deux volets.
Tout d'abord, c'est le premier volet, on peut concevoir de façon stratégique en identifiant certains éléments présentant une forte valeur et dont le business peut profiter. Si vous travaillez dans une société bien établie (pas une startup), il y a une grande probabilité que la valeur se trouve en relation avec un système légataire, historique. Vous pouvez alors utiliser le "Context Mapping" et faire de l'analyse par sous domaine ("Subdomain Analysis") pour vous aider à comprendre l'étendue de la problématique, ce qui révèlera un chemin clair vers une solution. Une fois que votre équipe a compris la direction stratégique, elle pourra déterminer les "Bounded Contexts" où la nouvelle valeur métier pourra être modélisée.
Généralement, une question se pose à ce moment. Quel est le meilleur moyen de s'intégrer avec le système légataire ? Ici, deux approches élémentaires se présentent. Si possible, vous pouvez faire en sorte que le système légataire publie des "Domain Events" clefs indiquant ce qui se passe en son sein. Le "Bounded Context" nouvellement mis en place se met à l'écoute et réagit aux "Domain Events" significatifs pour réaliser le comportement système attendu.
Je pense qu'il est la plupart du temps possible de trouver un moyen de publier quelques "Domain Events" clefs depuis le système légataire. Toutefois, il peut être peu aisé de faire de l'architecture du système légataire une complète architecture orientée évènement, une architecture "Event-Driven". Dès lors, il peut être également nécessaire de créer des moyens d'échange d'information additionnels entre le système légataire et le nouveau système. Je suggère ici de jeter un œil à deux approches stratégiques, "Open Host Service" et "Anticorruption Layer". Il existe d'autres possibilités, mais ces deux devraient être vues comme les approches fondamentales de l'intégration en DDD.
Remarquez bien que nous n'accordons pas ici un effort énorme à l'amélioration du système légataire. Nous ajoutons plutôt de façon incrémentale quelques points d'accroche au système, juste assez pour permettre au nouveau système de fonctionner. On pourrait éventuellement procéder à quelques petites réécritures mais l'expérience montre que cela peut bien souvent mener à l'échec. Souvent, même de petites modifications peuvent avoir des conséquences significatives et un grand nombre de tests existants peuvent se mettre à échouer si elles ne sont pas réduites au strict minimum. Essayer de faire face à toutes ces conséquences peut être difficile, chronophage et déstabilisant.
Enfin, c'est le deuxième volet, le nouveau "Bounded Context" pourrait être modélisé jusqu'à un degré plus ou moins important en utilisant une conception tactique en DDD. Il y a beaucoup d'intérêt à utiliser des Agrégats mais réussir une bonne conception des Agrégats présente de nombreux et gros challenges. Il est essentiel de porter une grande attention aux règles de base pour s'assurer le succès.
InfoQ : Certains peuvent être intimidés par DDD par le fait qu'il introduise un jargon spécifique, à cause de son apparente complexité et des manuels d'instruction de près de 600 pages. Est-ce que DDD est vraiment si difficile à implémenter ?
Oui et non. Je pense que cela dépend avant tout de votre bagage. Pour ceux qui sont très familiers avec la conception orientée objet et savent l'implémenter de façon correcte, la plupart des concepts viendront plutôt naturellement. Par contre, pour ceux qui sont habitués à des approches de développement centrées sur la base de donnée, avec une myriade de getters et setters au sein d'un domaine anémique, cela demandera plus de discipline. Ceci est principalement dû à la nécessité de revenir sur ses acquis, en plus de la quantité de nouvelles choses à apprendre. Dans ce cas, ce qui importe, c'est la détermination du développeur à changer sa manière de faire.
Mon livre est là pour rendre beaucoup plus facile aux deux groupes de réussir à utiliser DDD. Je vais me permettre d'en profiter pour faire la promotion de ma formation, le IDDD Workhop. J'anime actuellement une série d'ateliers en Europe, série qui est maintenant quasiment terminée. Une formation est prévue à Denver, dans le Colorado aux Etats Unis, du 22 au 25 Juillet 2013, à laquelle vous pouvez vous inscrire ici.
InfoQ : A quel type de résistance un praticien du DDD peut-il faire face lorsqu'il se trouve dans une organisation qui aurait besoin de ses services ? Comment peut-il venir à bout de cette résistance ?
Si vous pensez pouvoir changer toute votre entreprise, ou du moins une grande partie de votre entreprise avec DDD, vous échouerez. Vous échouerez que vous ayez le support du business ou pas. D'ailleurs, il est peu probable d'obtenir le soutien du business avec une idée extravagante comme celle de changer votre entreprise à grande échelle. A mon avis, la plus grosse erreur qui peut être faite avec DDD, c'est lorsqu'un groupe de développeurs et d'architectes déterminés partent pour en faire trop, même avec les meilleures intentions du monde. Cela terrifie réellement les managers exécutifs d'entendre qu'une équipe veut entreprendre des travaux majeurs impactant les systèmes existants, parfois même des réécritures complètes de multiples systèmes. Ce n'est pas effrayant seulement pour les exécutifs ; c'est effrayant pour n'importe qui ayant conscience de ce qu'il faut faire pour mettre en place DDD correctement, ou simplement pour réussir une telle entreprise, quelle que soit l'approche. Et cette situation est exacerbée quand ceux qui poussent DDD font beaucoup de bruit autour de leurs initiatives.
Je pense que la meilleure façon d'éviter la résistance du business est de commencer par trouver un moyen raisonnable de livrer une valeur métier concrète et significative au sein d'un nouveau périmètre, un nouveau "Bounded Context". Pour le premier projet, il est préférable d'agir sur un périmètre relativement restreint et de simplement s'assurer de livrer régulièrement, de respecter le budget et les délais. Cela ne veut pas dire que vous devez réaliser ce projet "en sous-marin", car vous aurez besoin d'obtenir une collaboration sérieuse de la part d'au moins un expert métier. Même s'il vous est possible de lancer un projet dans le secret, cela ne pourra vraisemblablement pas marcher sur la durée. Donc prévoyez un minimum d'impacts et restez raisonnables dans vos attentes concernant le projet.
Cela veut principalement dire que vous aurez à garder vos propres exigences ainsi que celles des autres développeurs sous contrôle. Tout ceci est un bon exercice qui force à penser comme le business pense, ce qui est plutôt important lorsqu'on compte implémenter DDD comme il se doit.
Ne faites pas trop de remous, volez au-dessous du radar, contentez-vous de livrer. Gagnez le respect et la confiance. Après que vous avez livré un projet ou deux, une fois que vous aurez apporté une valeur métier évidente, alors vous serez en meilleure position pour plaider la cause de DDD en vous appuyant sur vos propres succès et votre claire compréhension de ce qui devrait et ce qui ne devrait pas être utilisé.
InfoQ : Finalement, est-ce que tous les domaines verticaux sont de bons candidats pour DDD ? Est-il possible qu'un sous-ensemble du système puisse maintenir son propre niveau de complexité alors que le reste du système augmente en complexité ?
Ce qui convient le mieux à DDD est de s'intéresser aux parties les plus complexes de votre business et à celles qui vont générer la plus grande valeur métier. Ceci signifie généralement que certaines parties du business ne méritent pas l'investissement dans une démarche DDD. Ceci dit, cela ne veut bien sûr pas dire que l'utilisation de pratiques de développement saines, possiblement basées sur DDD, ne devraient pas être employées sur les zones où le besoin est moins évident. Ce que je veux dire, c'est que ce n'est pas parce que une partie du business n'est pas considérée comme étant d'importance stratégique qu'elle doit être implémentée de façon médiocre. Même les logiciels génériques ou secondaires sont essentiels à l'opération dans sa globalité et interviennent d'une certaine façon dans la solution de bout en bout. Seulement, vous n'aurez simplement pas besoin de la même implication des experts métier que sur le vrai cœur du domaine.
Ce qui surprend parfois une équipe, c'est qu'un système ou un sous-système qu'elle n'aurait jamais imaginé être au cœur du domaine le devienne à un moment donné ou du moins joue un rôle plein dans une nouvelle initiative majeure. Cela veut-il dire que vous devriez essayer d'anticiper la probabilité de voir de telles choses se passer et que vous devriez passer du temps à modéliser au plus tôt en faisant comme si cette partie du système allait réellement requérir un investissement sur DDD ? Je ne pense pas que cela soit très sage. Déjà, je dirais que vous devriez toujours donner les moyens à votre équipe de développer le mieux possible, même s'elle n'est pas amenée à coopérer de façon régulière avec des experts métier. Mieux le système sera conçu, plus il sera facile de le faire évoluer, de le maintenir et de l'étendre si on en vient à lui donner un rôle plus significatif que celui qu'il avait jusqu'alors.
Je pense que le point à retenir ici, c'est que vous devez avant tout savoir quand et comment utiliser DDD correctement et ne pas considérer qu'un système non candidat à une approche DDD soit un prétexte à des implémentations faisant fi de la qualité. Ce serait simplement irresponsable.
Encore un conseil. Même un système modélisé sans DDD est susceptible de publier des "Domain Events" importants ou fournir un "Open Host Service" comme partie de son contrat de service. Souvenez-vous que même un système dépassé peut être amélioré à la marge pour lui permettre de publier des Domain Events, sans pour autant que cela représente un chamboulement trop important. Tout ceci ne nécessite pas un investissement important dans une démarche DDD car vous pouvez n'impliquer qu'une ou quelques équipes pour travailler sur les Domain Events ou les API strictement nécessaires pour pourvoir échanger les informations avec votre système. Et si votre contrat se trouve alors prendre une place importante de la démarche globale, vous pouvez en venir à la création d'un "Published Language" au niveau de l'organisation, autre composant de la conception stratégique avec DDD.
Dans mon livre, vous pourrez trouver une illustration de cette approche à travers l'exemple de contexte lié à l'identité et aux accès (Identity and Access Context) présenté parmi les exemples de modèles. L'"Identity and Access Context" est considéré comme un sous-domaine générique et ne bénéficie pas d'un investissement DDD. Toutefois, il est conçu correctement, publie des Domain Events importants et inclue un Open Host Service pour permettre aux autres système, les systèmes DDD fondamentaux, de s'intégrer avec lui.
InfoQ : Si quelqu'un aspirant à pratiquer DDD voulait utiliser DDD pour améliorer son produit, par quels concepts lui conseillerez-vous de commencer ?
Vous pouvez tirer de nombreux bénéfices en commençant par l'étude du problème dans son ensemble, en utilisant les Context Maps et les sous-domaines puis en identifiant un nouveau Bounded Context en tant que cœur du domaine. Vous vous apercevrez que les Domain Events et les Agrégats jouent un rôle essentiel dans la conception tactique. Là où c'est possible, vous devez vous appuyer sur des Value Objects plutôt que sur des Entités. Toute occasion de recourir à l'immutabilité ou à des fonctions sans effet de bord vous épargnera beaucoup de problèmes.
Vous pourrez voir des illustrations de l'utilisation de diverses techniques de modélisation stratégiques et tactiques dans les exemples du livre, en Java et en C# :
InfoQ : Récemment, beaucoup d'idées relativement nouvelles sont en train de gagner en dynamisme dans la grande communauté du développement logiciel : DDD, Event Sourcing, NoSql et la programmation fonctionnelle pour en citer quelques-unes. DDD semble bien s'accorder avec chacun de ces concepts. À votre avis, sur quoi cette dynamique pourrait déboucher ?
Les principes de l'approche DDD sont utilisés depuis longtemps, avec diverses technologies, divers patterns, styles et influences idiomatiques. Donc, pour répondre simplement, je pense que DDD pourra être utilisé de la même façon dans le futur proche, tel qu'on peut l'envisager. Il me semble que concernant Event Sourcing, comme NoSql, c'est un fait établi. On est par ailleurs en train de gagner en expérience autour de l'utilisation de DDD avec la programmation fonctionnelle, d'autant plus que la programmation fonctionnelle devient réellement utilisée.
Un style d'architecture que vous n'avez pas mentionné, c'est le modèle acteur. Je suis moi-même en train de développer une expérience et des outils autour de l'utilisation du modèle acteur avec DDD. Dans un environnement de programmation fonctionnelle, cela pourrait correspondre à un modèle agent, plutôt qu'acteur, mais dans ces deux modèles, il y a une emphase sur l'échange de messages, les modèles de concurrence non-bloquante et les environnements hautement distribués. C'est un des moyens cruciaux par lesquels on peut obtenir plus des cœurs de nos machines, toujours plus nombreux, en obtenant une meilleure efficacité des processeurs individuellement. L'idée fondamentale du modèle acteur simplifie énormément les efforts pour comprendre et utiliser la concurrence et les modèles distribués.
Si vous souhaitez vous essayer au modèle acteur, vous pourrez trouver mon projet expérimental ici.
Pour des systèmes acteurs complets, vous pouvez également vous tourner vers le projet Akka pour Scala ou Java. Si vous travaillez sous .Net, vous pouvez essayer ActorFx de Microsoft.
Au sujet de l'auteur
Vaughn Vernon est un vétéran de la communauté du développement logiciel, avec plus de 25 années d'expérience dans la conception, le développement et l'architecture, leader d'opinion cherchant à simplifier, par des méthodes innovantes, la conception logicielle et l'implémentation. Il programme avec des langages orientés objet depuis les années 80 et applique les fondamentaux de Domain Driven Design depuis le temps où, dans les années 90, il modélisait les domaines sur lesquels il travaillait en Smalltalk. Son expérience couvre un large panel de domaines métier, parmi lesquels l'aérospatial, l'environnement, le géo-spatial, l'assurance, le médical et la santé, et les télécommunications. Il a également connu plusieurs succès dans le domaine technique avec des Frameworks, librairies et outils de productivité. Il fait du conseil, parle dans des conférences à l'international et a tenu ses formations sur Implementing Domain Driven Design sur plusieurs continents. Vous pouvez en savoir plus sur ses récents travaux sur son blog et le suivre sur Twitter : @VaughnVernon.