On (Anthony et Colin) continue notre dernier jour de conférences à DDD Europe 2020 et cet article conclura notre passage à Amsterdam !

Architect’s Survival Guide to Healthcare par Sonya Natanzon

Sonya Natanzon, architecte chez Genomic Health, une entreprise spécialisée dans la recherche génétique et notamment dans la détection du cancer, nous parle de son expérience au sein de son entreprise.

Elle commence un talk très touchant en mettant en avant l'importance du Domain médical qu'elle met en parallèle d'un Domain qui a très souvent été présenté pendant la conférence : celui de la banque.

Elle explique avoir pris pleinement conscience de l'importance de ce Domain mais aussi de sa complexité lorsqu'une leucémie à été diagnostiquée chez son mari. A ce moment, elle a découvert la complexité du langage médical qui n'est tout simplement pas compréhensible pour les non-initiés (contrairement au langage bancaire, par exemple).

Elle nous rappelle alors l'importance de l'Ubiquitous Language dans ce type de Domains complexes et peu maîtrisés par la majorité des équipes de développement.

Depuis ces événements, elle s'est spécialisée dans les applications à vocation médicale et nous propose donc un retour d'expérience d'utilisation du DDD dans ce type d'environnement techniquement très spécifique.

Les architectures dans lesquelles elle évolue sont basées sur des ERP, des CRM et pléthore d'autres solutions absolument pas construites pour répondre à un besoin spécifique. Elle insiste sur les problèmes de couplage entre les solutions "maison" et ces solutions du marché. En fait, le couplage est même tellement fort qu'elle travaille avec un Monolithe Distribué.

Même si nous savons que cet anti-pattern est très nocif, il y a eu une image très parlante pendant l'un des talk (mais nous avons oublié lequel...) : "Il vaut mieux un gros tas de m***e que de la m***e étalée de partout". De fait, quand elle évoque ce terme, nous imaginons aisément les difficultés qu'elle rencontre au quotidien.

Comme on pouvait s'y attendre, elle a rassemblé les choses pour, ensuite, faire des découpages autour du métier (et des patients) et non pas des contraintes techniques. Malheureusement, dans le Domain médical, certains outils ne peuvent êtres supprimés, les développeurs sont donc forcés de garder certains découpages techniques.

Une fois le découpage un peu plus logique, elle a appris à se préparer aux audits (qui sont monnaie courante dans le domaine médical) en anticipant les demandes des auditeurs qui veulent des documents que l'on aimerait beaucoup ne pas avoir à produire. En étant capable de générer facilement des BPMN et autres "documents d'architecture" très éloignés de la logique du DDD, elle a pu se faciliter le quotidien et largement diminuer ce problème.

En tant qu'adeptes de méthodes de travail itératives centrées sur la réponse aux besoins métier, nous avons eu, sur le coup, une réaction épidermique aux diagrammes illisibles qu'elle a présentés (et qu'elle présente lors des audits). Cependant, avec le recul, nous nous rendons compte que ces diagrammes font partie de son métier.

Certes, ils n'apportent aucune valeur dans les solutions mais, sans eux, les solutions ne peuvent pas être utilisées car elle ne reçoivent pas les agréments nécessaires. De fait, dans ce genre de cas, lorsqu'on ne peut pas changer les règles du jeu (comme dans le cas de la loi), il peut être intéressant de s'outiller pour répondre à moindre coût à ces contraintes souvent déconnectées de la réalité.

Au final, un talk intéressant qui nous rappelle que, dans certains cas, la solution pragmatique peut être de donner aux gens ce qu'ils demandent (même si on sait pertinemment que cela n'apportera rien à la solution). On a aussi confirmé, une fois de plus, qu'il vaut largement mieux avoir un Monolithe qu'un Monolithe Distribué qu'on appellerait micro-services.

Systems Thinking and the Art of Simplification par Lorraine Steyn

Un talk sur le Systems Thinking par Lorraine Steyn, un sujet qui nous est totalement inconnu, un talk avec beaucoup d'informations : on ne va pas lui faire honneur ici…

Après une brève présentation de quelques uns des principes du Systems Thinking  (Rasoir d'Ockham, Success to the Successful, Rule Beating, …) Lorraine nous donne une manière de modéliser un Système :

Dans cette représentation, on place :

• Au centre ce que l'on veut modéliser ;
• A gauche les entrants, ce qui va aider à la réussite (Inflows) ;
• En dessous les contradictions (Discrepancy), ce qui au final ne sert pas notre but ;
• Tout en bas le but à atteindre ;
• Et à droite les éléments sortants qui pourraient empêcher l'atteinte de l'objectif.

En suivant ce modèle nous essayons, en séance, de faire le modèle d'efficacité d'une équipe de développement. Nous arrivons à ce résultat :

Puis, Lorraine présente le modèle auquel elle est arrivée lors de sessions précédentes :

On retrouve sensiblement les mêmes choses ce qui s'explique simplement par le fait qu'elle a beaucoup guidé l'atelier :). Par exemple, les policies avaient été mises dans les Outflows (pas dans les Inflows) mais Lorraine, en tant que chef d'entreprise, a tenu à ce que les règles de l'entreprise soient une aide et non un frein.

Après d'autres conseils concernant des sujets aussi divers que la manière de gérer son énergie ou comment faire des schémas lisibles, elle conclura en disant :

"Systems always behave exactly as they are designed, just not always as they are intended."

"Be creative and courageous about systems redesign."

Au final, ce fut un talk qui nous a plus même si nous n'avons pas pu en tirer tous les enseignements. Nous en sortons avec des sujets intéressants à creuser ou simplement à laisser maturer.

Lightning talks

Nous avons hésité à aller voir les Lightning Talks puisque le talk de la veille sur cette plage horaire nous a beaucoup marqué. Pour être tout à fait honnêtes, si nous nous étions un minimum renseignés et si nous avions su qui était Aslam Khan (le speaker faisant l'autre talk), c'est probablement lui que nous serions allés voir !

Mais, en fait, on a vu 3 très bons talks pendant cette heure ! Malheureusement, nous n'avons pas les vrais titres des talks mais on va quand même vous en parler.

DDD Iceberg par Marco Consolaro

Le premier talk qui nous a marqué était présenté par Marco Consolaro et on en a retenu son Iceberg du DDD. Dans cette présentation il introduit les pré-requis suivants au DDD :

• Pair Programming;
• Classic TDD;
• Transformation Priority Premise;
• Object Calisthenics;
• Code smells;
• Refactoring;
• 4 Elements of Simple Design;
• Cohesion / Coupling / Connascence;
• Tests doubles;
• Outside in TDD;
• Design patterns.

Marco explique ensuite comment il accompagne des équipes de différentes entreprises dans l'apprentissage de ces bases en utilisant beaucoup de Mob Programming. L'exemple d'utilisation de cette approche pour l'enseignement dans notre article dédié vient justement de ce Lightning Talk.

Nous avons été très réceptifs à ce talk et à ces pré-requis puisqu'on a reconnu ce qu'on pouvait dire au cours des échanges avec les participants pendant les jours précédents.

La rapidité des résultats qu'il obtient en basant son enseignement sur des sessions de Mob nous a bluffé et nous allons nous y essayer dès que l'occasion se présentera (en fait, elle s'est déjà présentée pour Anthony et les résultats sont bons).

En plus de la manière d'enseigner, nous retenons une liste de prérequis plus formalisée que celle que nous pouvions avoir en tête. Il est fort probable que l'on réfléchisse à notre propre iceberg du DDD dans un avenir proche.

Types Driven Development

Ce second talk est présenté par Arnaud Bailly. Il parle de TDD, mais le premier "T" est pour Types. Il nous explique que, pour s'essayer à Idris, il a voulu faire un modèle de Domain. Il s'est alors rendu compte qu'en utilisant correctement les types pour représenter son métier il était "forcé" de faire les choses de la bonne manière.

En fait, il est possible de s'y prendre mal, mais ce sera bien plus compliqué que de faire des choses logiques. Utiliser un typage fort guide non seulement notre implémentation mais aussi la réflexion métier que l'on peut avoir sur notre Domain. Ce guide vient du fait que les types vont naturellement empêcher les opérations et peuvent donc nous amener à rendre implicites certains explicites !

Au quotidien, nous travaillons en Java et en Typescript, des langages qui ne sont pas naturellement fortement typés, mais nous essayons d'introduire au maximum des types et de suivre ce paradigme depuis quelque temps déjà.

Avant ce talk, nous étions déjà convaincus de l'importance des types mais nous n'avions pas encore poussé la réflexion jusqu'à guider l'analyse du métier par les types. Un nouveau point à garder dans un coin de la tête, peut être ressortira-t-il un jour.

Liskov

Le dernier Lightning Talk qui nous a marqué était présenté par Pedro M. Santos et l'idée initiale était de parler du principe de Substitution de Liskov (le L de SOLID).

Pedro commence par un rappel du principe et du but des héritages : "Un carré n'est pas un rectangle avec des côtés égaux puisqu'un rectangle a, par définition, des cotés qui ne sont pas égaux".

En réexpliquant Liskov et la validation des préconditions, des invariants et des postconditions, il explique qu'on peut construire des solutions :

• Robustes ;
• Résilientes ;
• Fiables.

Ce talk nous a ouvert les yeux sur l'importance de ce principe mais nous devons encore laisser tout ça mûrir pour pouvoir en faire un retour intéressant. Pour le moment, tout ce que l'on peut dire, c'est qu'on a bien aimé et qu'il peut être intéressant de réfléchir là-dessus :).

Elephants, Patterns, and Heuristics par Rebecca Wirfs-Brock et Christian Kohls

On termine cette journée incroyable par un talk au titre plus ou moins étrange de Rebecca Wirfs-Brock et Christian Kohls.

Bien entendu, le titre fait référence à la Anekantavada (mais si, les aveugles et l'éléphant !) et, même si il y avait certainement bien plus à en retenir, nous retiendrons surtout des enseignements liés à, justement, l'enseignement.

Ce talk parle du Design Pattern Observer et va s'amuser à regarder différentes représentations de ce même Pattern, en commençant par celle du GOF. Les speakers mettent très rapidement le doigt sur un point important : non seulement sa représentation n'est pas la même en fonction des versions de Wikipedia mais certaines représentations sont tout simplement fausses !

Bien entendu les versions identifiées fausses ont été corrigées par les speakers avant la conférence.

Le fait que les versions diffèrent est intéressant, cela s'explique simplement par une volonté de rendre l'explication plus claire pour les lecteurs. Malheureusement, dans le cas des Design Patterns il est très simple d'introduire des erreurs dans les représentations.

Pour ces deux experts, les erreurs seront évidentes et ils pourront simplement les corriger mais ce n'est pas le cas des personnes découvrant le sujet, celles-là même pour qui une représentation simplifiée a été faite !

En voulant simplifier la représentation d'un problème complexe pour en faciliter l'apprentissage, les auteurs enseignent en fait des choses fausses ! Ces mauvaises représentations entraîneront alors de mauvaises implémentations et, de fait, des promesses non tenues.

Rebecca et Christian soulèvent alors la question de l'adaptation de la représentation en fonction des interlocuteurs. Certes, il faut toujours garder une représentation juste mais, dans certains cas, cette représentation juste ne pourra tout simplement pas être comprise.

Du coup, est-ce qu'il vaut mieux, parfois, donner une représentation un peu fausse (mais tenant quand même les promesses initiales) pour permettre aux interlocuteurs de comprendre ? Est-ce toujours possible ?

Dans certains cas, le meilleur moyen n'est-il pas de donner les pistes permettant à chacun de faire ses propres découvertes ?

Et en dehors des talks ?

En plus de la qualité tout à fait impressionnante des talks auxquels nous avons assisté, ce qui nous a marqué, c'est le très grand état de fatigue dans lequel nous étions (et pourtant on a été très sages).

Assister à des talks incroyables, échanger avec les participants en utilisant la technique du pac-man et essayer de perdre le moins d'informations possible aura rapidement eu raison de notre endurance.

Au final, on aura passé 4 jours mémorables à Amsterdam parce que oui, on est quand même allé faire un peu de tourisme avec des centres d'intérêt parfois différents. Pendant que Colin prenait en photo les bâtiments

Anthony, lui, s'intéressait plus aux fromages...