Devoxx France 2016 : Architecture & méthodologie

Cet article présente les différentes conférences orientées architecture et méthodologie vues lors du Devoxx France 2016 :

Modular Monoliths

Orateur Simon Brown, vu par Eymeric VIEUILLE

Cette conférence a proposé une manière de structurer ses projets de façon à pouvoir traduire jusqu’au code chaque élément de son architecture.

Le modèle C4

Le modèle C4 consiste à décrire son architecture en quatre diagrammes :

La structure usuelle des conteneurs

La façon fréquente de structurer ses conteneurs a les défauts suivants :
1) Penser en composants mais écrire des classes
2) Organiser ses classes en couches :

La structure préconisée

Niveau 1 : Le système va naturellement se matérialiser par l’ensemble des conteneurs qui le constituent. Ses interactions extérieures par des interfaces spécifiées avec le monde extérieures.

Niveau 2 : Le conteneur contenant du code va se concrétiser par l’existence d’une application.

Niveau 3 : Les composants pourront être regroupés et identifiés par la création d’un paquetage propre à chacun d’eux. Ainsi, chaque composant pourra se structurer en couches de la façon suivante :

Chaque composant pourra définir une interface constituant un service. Ce dernier sera réalisé par une implémentation concrète pouvant utiliser une classe de persistance (DAO).
Niveau 4 : Le niveau 4 est naturellement incarné par les classes disponibles au sein de chaque paquetage.

Ainsi, la solution préconisée est un mixte entre l’application monolithique et le système de micro services :

Le micro service ne devra être employé que pour bénéficier de ses avantages :
– Le déploiement unitaire du service
– La mise à jour unitaire du service
– L’empilement de technologies hétérogènes

Toutefois, se pose la question des classes du modèle métier : Où les mettre ? Dans un composant ou ensemble ?
C’est une question qui devra être tranchée au cas par cas selon les spécificités de l’application.

Les répercussions sur les tests

Aujourd’hui, la vision est essentiellement pyramidale :

Avec le découpage préconisé en micro services, il faudra probablement revoir cette conception des tests pour converger davantage vers ce type de modèle :

Que penser de tout cela ?

La présentation de Simon Brown est de très bonne qualité et permet de formaliser des réflexions menées depuis quelques années déjà sur le découpage des applications en composants. La solution préconisée est efficace, facilite le passage à une solution SOA mais est très perméable à des ajouts de dépendances non souhaitables entre composants dans le cas d’une application monolithique. Elle devra donc s’accompagner d’outils comme JDepend pour visualiser graphiquement les dépendances entre paquetages. Ainsi, l’architecte peut tout de suite identifier de nouvelles dépendances non désirées entre composants et garantir la pérennité de cette bijection entre l’architecture et le code.
Toutefois, la partie de la présentation concernant les tests est plus discutable. En effet, Simon Brown préconise de marginaliser les tests unitaires pour privilégier les tests composants. Il faut peut-être nuancer ce discours en préconisant une forte couverture par tests unitaires des composants critiques et effectivement privilégier les tests composants dans les autres cas.

Les slides / La vidéo

 

DDD, en vrai pour le développeur

Orateur Cyrille Martraire, vu par Eymeric VIEUILLE

Cette conférence apprend à mieux scinder les problématiques techniques (gestion des transactions, base de données, etc.) et les problématiques métier afin de mieux faire ressortir ces dernières.

Ubiquitous language

La première idée importante à assimiler pour appliquer DDD dans son projet : c’est que le métier est important. La première étape consiste donc à en dégager un langage métier commun qui pourra être compris par l’ensemble des intervenants et qui sera le plus fidèle possible à la réalité métier. C’est le langage du domaine.

Le meilleur moyen de savoir si DDD est bien appliqué sur le projet est de passer son code dans un word cloud (Ex : http://www.wordclouds.com/) afin de voir quels sont les mots qui ressortent (à gauche la technique est mise en avant, à droite le métier est mis en avant).

Il est très important de bien comprendre le métier pour appliquer DDD.

Quand appliquer DDD ?

DDD doit être appliqué lorsque :

  • le risque est dans le métier (ex : algorithme de facturation client)
  • la différenciation est dans le métier (ex : algorithme de détection temps réel plus rapide que celui du concurrent)

Le reste du temps DDD n’a pas besoin d’être appliqué.

Comprendre le métier

La deuxième bonne pratique à mettre en œuvre en complément de DDD est d’utiliser une méthode appelée BDD (Behaviour Driven Development).

Celle-ci consiste notamment à établir avec les différents intervenants des scénarii d’utilisation par l’exemple. Ces scénarii sont regroupés par fonctionnalité et sont structurés avec des phrases de type Given-When-Then.

Exemple :

Scenario: Motion detection

Given one initial picture
When pixel changed in next picture
Then something moved

Ces scénarii et une bonne connaissance du métier va permettre au développeur de prendre de meilleurs décisions. En effet, le développeur doit souvent prendre des microdécisions qui ne sont pas indiquées dans la spécification. En ayant une meilleure connaissance du contexte, celles-ci seront plus pertinentes.

Modéliser le domaine

Naturellement, le code tend à se concentrer (parfois au sein d’une seule et même classe). La modélisation est très importante pour contrer ce phénomène.

La préconisation, faîte lors de cette conférence, est de modéliser en se basant sur notre compréhension du domaine métier.

Pour savoir si la modélisation est correcte, plusieurs critères sont identifiés :

  • Le code fonctionne et passe tous les scénarii définis
  • Le code nous permet de comprendre le métier et est fidèle à notre façon de comprendre le métier
  • Le système logiciel tend à refléter la structure du domaine métier et les zones fonctionnelles sont matérialisées par les modules dans le code


Pour aider à la modélisation, il existe des patterns tactiques.

Trois types de classes y sont identifiés :

  • Les value objects : ils sont identifiables en faisant une égalité champ par champ des propriétés de la classe. Ils sont immutables, n’ont pas de getters et setters
  • Les entités : elles évoluent dans le temps et sont identifiables via un identifiant
  • Les services : ils ne sont ni une value ni une entité et ils les manipulent.

Le modèle métier est regroupé et les services ne doivent pas être appelés explicitement dans celui-ci. Le service pourra y être utilisé en définissant une interface et en utilisant l’injection de dépendance. De plus, l’interface du service devra porter un nom qui correspond à une réalité métier.

Par exemple, la problématique de persistance pourra être résolue à l’aide de la notion de repository (en n’oubliant pas d’identifier la notion métier qui se cache derrière ce dernier). C’est ainsi que la persistance d’une liste de produits pourra se traduire au sein de notre modèle métier à l’aide de la notion de catalogue. Et c’est le catalogue qui pourra ensuite être persisté.

Ainsi, avec toutes ces mécaniques, il apparaît clairement que les choix de conception se font grâce à la compréhension du domaine métier.

Illustration : Ajoutons une adresse de livraison dans le cadre d’un achat.

La première solution venant à l’esprit est la suivante :

Mais cela traduit une mauvaise compréhension du métier. Le métier est fait de sous-domaine. Avec une meilleure compréhension du métier, les sous-domaines suivants sont identifiés :

Ainsi de façon générale, une adresse pourra être vue de façon différente en fonction du sous-domaine métier considéré (facturation, envoi, etc.). Ce sous-domaine considéré est également appelé contexte borné.

Contexte borné : représentations d’une adresse en fonction du sous-domaine

Que penser de tout cela ?

Cette présentation vient en complément d’autres présentations déjà faîtes sur l’architecture hexagonale. Elle recoupe également d’autres domaines proches tels que le Test Driven Development (notamment avec des technologies de type Cucumber). DDD est très intéressant car il regroupe des connaissances déjà identifiées sur la façon de structurer et découper le code (ex : MVC) tout en poussant la logique plus loin. Cyrille Martraire a le mérite de faire une présentation claire sur un sujet complexe et très abstrait.

La vidéo

 

Living Documentation : vous allez aimer la documentation !

Orateur Cyrille Martraire, vu par Aurélien BAUDET

Le but de la documentation est un passage de connaissance. La documentation n’est utile que pour le long terme, à destination d’un large nombre ou qui contient des informations critiques (que tout le monde doit savoir). Pour tous les autres cas, il vaut mieux privilégier d’autres techniques de transmissions plus efficaces que la documentation.
Dans le cas où le choix se porte sur la documentation, il faut rendre l’information accessible à tous (le public final n’est pas forcément technique).
Actuellement, la documentation est une source de frustration. Lorsqu’on consomme une documentation elle est souvent obsolète. Ecrire une documentation est une tâche ennuyeuse. Utiliser des outils traditionnels tels que Word pour écrire de la documentation peut faire perdre du temps (par exemple, déplacer une image dans le document Word peut casser la mise en page).
Les développeurs préfèrent donc coder plutôt qu’écrire de la documentation !
Pourtant le code est de la documentation : lire le code raconte le fonctionnement du métier.
L’objectif de sa présentation est de montrer comment améliorer à la fois la documentation et le code en utilisant les approches DDD (Domain Driven Design : voir ci-dessus), BDD (Behavior Driven Development) et un bon outillage.

En utilisant l’approche BDD, des outils nous simplifient déjà le travail :

 

On peut utiliser le langage de description Gherkin pour écrire nos scénarios métier. Cucumber et Specflow peuvent générer de la documentation et automatiser l’exécution des tests. Pickles permet quant à lui de générer un site Web.
L’approche DDD préconise d’utiliser les termes métier et d’organiser le code pour correspondre à ce métier. Le découpage des packages suit alors le découpage métier. Ce principe associé à des commentaires dans le code permet encore une fois de générer de la documentation :

Nous avons donc nos spécifications à jour avec le code et notre glossaire métier. Souvent, un schéma est plus efficace qu’une longue documentation. Pour avoir des diagrammes à jour avec le code, le principe est le même que précédemment, on scanne le code, on traite les annotations et on génère un diagramme (avec Graphviz par exemple). Pour des diagrammes d’explication, il nous conseille d’utiliser un format textuel et de générer le graphique. Le diagramme est dans le code et peut donc être mis à jour en même temps qu’un refactoring.

Avec toutes ces méthodes et outils, on a donc ce qu’il appelle du « Living documentation », « Living glossary » et « Living diagram ».

La documentation est maintenant toujours en phase avec le code. L’organisation de la documentation reflète le design de l’application. De son point de vue, si vous éprouvez des difficultés à avoir une bonne documentation auto-générée c’est sûrement que le design de l’application est mal pensé. De plus, essayer d’avoir une documentation bien organisée force à améliorer le design de l’application.

Cyrille Martraire a également fait un aparté intéressant sur le DDD (Domain Driven Design) pour nous expliquer que la méthode la plus efficace pour comprendre le métier c’est de le voir par soi-même sur le terrain.

Nous avons déjà mis en place des systèmes équivalents (avec Sphinx et des plugins maison) pour avoir une documentation la plus automatisée possible à partir du code. L’objectif n’était pas le même : il nous fallait une documentation d’utilisation et non une documentation du métier. Les idées qu’il apporte sont très intéressantes que ce soit d’un point de vue méthode mais aussi d’un point de vue automatisation. Suite à sa conférence, on a envie de tester les principes, le seul bémol étant que les outils n’existent pas sur le marché et qu’il faut les développer soi-même pour le moment.

Les slides / La vidéo / Le livre

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

14 + 4 =