Dans l’article précédent nous avons effleuré le concept de design stratégique. La phase indispensable qui consiste à analyser notre système sous l’aspect et dans le référentiel du problème (par opposition à la solution).
J’ai insisté sur le fait que l’analyse du domaine est une étape incontournable. C’est souvent une étape oubliée, mais c’est fondamental lorsqu’on prétend répondre à un problème précis.
C’est ce qui est souligné dans l’épisode 7 de Clean code. (Une série que je recommande tant pour le contenu pédagogique que pour l’humour désopilant d’Uncle Bob.)
Mais également clairement le fondamental de “Domain-Driven Design: Tackling Complexity in the Heart of Software” d’Eric Evans.
Et que l’on retrouve subtilement dans cet article de Martin Fowler.
Pour rappel un de nos objectifs est de partitionner et découpler un système complexe afin de le rendre plus maintenable et évolutif.
La formulation du problème sous forme de sous-ensemble de problèmes. Ou Domain et Sub-Domain vont nous permettre plus tard d’accomplir le partitionnement de la solution (le système) en composants spécialisés dans résolution d’un sous-problème.
Si nous suivons ce principe, l’architecture de notre système devrait aboutir à une représentation employant des concepts identiques à celui du domaine du problème. (Nous détaillerons ceci dans la suite de la série d’articles)
Il est un autre point sur lequel je souhaite insister : la modélisation du problème comme de la solution, sont des processus itératifs. Ce ne sont ni des finalités, ni des résultats.
Ainsi évitons de penser « J’implémente le DDD » mais plutôt « J’oriente la conception en me basant sur l’observation du domaine »
Ou encore « c’est de la Clean Architecture » mais plutôt « Lorsque j’implémente une solution, je veille à ce qu’elle ne soit pas en contradiction avec les principes SOLID »
C’est un peu à l’image du rémoulage de lames. Un de mes passe-temps favori. Les techniques sont multiples, ma préférée est le rémoulage depuis la pierre à gros grains puis de plus en plus fin jusqu’au polissage.
Je peux passer 10 minutes ou 2 heures sur un couteau, le processus est le même : Dégrossir le taillant avec un angle constant. Une fois le fil formé sur l’angle du taillant je passe au polissage qui va me donner la finition.
Mais une fois ce cycle effectué suivant le résultat que je souhaite atteindre — couteau pour les enfants ou rasoir… l’objectif est différent — je peux décider de relancer un cycle.
C’est un processus quasiment sans fin (sauf quand la pierre ou la lame a complètement disparu :))
L’analogie continue, à l’usage le fil de mon couteau s’émoussera il faudra donc entretenir celui-ci. Et donc renouveler le processus.
Et pour finir, l’expérience accumulée dans les précédents rémoulages, me permet de limiter la vitesse à la quelle le fil s’émoussera.
Est-ce qu’on peut entrer dans cette démarche pour tous les projets ? Probablement non, mais je n’ai pas de contre-exemple en tête.
Mais c’est une démarche qu’il convient d’entreprendre, que le projet soit nouveau tout beau, ou alors une infâme patate chaude.
Même dans le contexte de l’existant, l’analyse stratégique va permettre de faire évoluer le système et de l’assouplir petit à petit (il faudra peut-être des années).
Puisque le sujet est sérieux et critique, il me semble nécessaire d’apporter un second cas pour illustrer le tout.
Nous allons nous projeter dans un autre cas, il s’agit d’une application à destination des joueurs de Go. Elle permet de jouer en ligne ou localement et de suivre sa progression au jeu de Go.
Je ne vais pas m’attarder sur la présentation de cet extraordinaire jeu de Stratégie originaire de l’Empire du Milieu sous le nom de Weiqi (Wei chi) et popularisé par l’Empire du Soleil Levant.
Vous trouverez tout ce qu’il faut sur le sujet en ligne dans votre langue favorite.
Faire en sorte que le système soit une implémentation de la solution qui utilise des représentations métaphoriques du domaine du problème, sous-entend qu’on utilisera le langage du domaine partout.
Tout au long de notre analyse nous devons collecter les termes du champ lexical de nos domaines et sous-domaines.
Ce sont ces termes qui devront être utilisés dans l’expression des tickets, la documentation, les réunions de projet, le code, les tests, les diagrammes, …
C’est pour cela qu’on l’appelle l’Ubiquitous Language.
C’est une notion que l’on retrouve de nouveau dans les préconisations des experts précités. Parce qu’elle est une des clés de la lisibilité d’un projet tout entier mais surtout de sa cohérence !
Dans le domaine du GO un plateau de jeu s’appelle un Goban. Nous retrouverons donc Goban à tous les échelons de la communication ainsi que dans le code.
À la place de game.current_playing_board (qui est un nom pas trop déconnant) nous aurions game.goban
Mon conseil pratique est que l’équipe maintienne un lexique pour chaque domaine / sous-domaine.
Dans un premier temps on peut dresser la liste des problèmes ou des situations auxquelles le système doit répondre.
En d’autres termes, ses Use Cases de haut niveau ! (Tout se recoupe…)
Partant de ces fonctions attendues, nous allons tenter d’identifier quels sont les domaines concernés.
Dans une première approche naïve nous résumons ceci au domaine du jeu de Go .
Hum nous voila bien avancés… Il doit y avoir une erreur quelque part. Le domaine du jeu de Go concerne tout ce qui tourne autour du jeu en lui-même, ses règles, ses pierres, les différentes tailles de Goban…
Mais est-ce que je réponds à mes Use Cases uniquement avec les règles du jeu de Go ? Non.
Si on reprend nos Use Cases :
Il est question de parties en ligne sur des serveurs existants. Peut-être que le domaine du jeu en ligne est davantage une description de notre domaine ?
Pas tout à fait non plus. Car il est aussi question d’analyse et de visualisation. Le concept d’analyse et de visualisation d’une partie semble ne pas se situer dans le domaine du jeu de go en tant que tel. Mais dans un domaine qui vient en support à celui-ci.
Il en va de même de la partie contre une IA ? Non, notre domaine ne se résume pas à celui de l’intelligence artificielle.
Alors que dire du suivi de progression et de ranking ? À quel domaine fait-il référence ?
Finalement avec une expression plutôt claire des Uses Cases et une première analyse, il apparaît que déterminer le domaine n’est pas si simple. Que plusieurs domaines semblent se chevaucher. Mais rien de cohérent n’en sort.
C’est tout simplement car nous manquons de contexte par rapport au problème global. Pour modéliser il nous faut creuser plus profond.
Un bon filon à exploiter pour avancer plus loin, consiste à identifier les raisons profondes de concevoir le système. Qu’est-ce qu’il apporte à ce qui existe déjà ? Qu’est-ce qui fait sa raison d’être ?
C’est en interrogeant les parties intéressées que nous obtenons en général la réponse.
Qu’est-ce qui fait que notre plateforme de jeu est unique ? Nous interrogeons l’équipe produit :
« Notre plateforme est compatible avec plusieurs serveurs disponibles » Qu’entend-on par compatible ? « L’usager peut démarrer une partie sur un de ces serveurs et la jouer, nous gardons l’historique de la partie pour ensuite l’analyser »
« Notre plateforme dispose d’une fonctionnalité d’analyse de jeu poussée et intelligente, elle permet de repérer les différentes situations dans le déroulement d’une partie. Comme les yeux, les catégories de groupes, les Shichô et Geta… » D’accord on est bien loin de la simple visualisation de parties donc.
« Nous centralisons également les résultats de toutes les parties jouées depuis la plateforme, qu’elles soient en ligne ou locales, nous les historisons, de manière à fournir des indicateurs sur le niveau comparatif du joueur. C’est un indicateur de progression. Mais aussi une bibliothèque de parties souvenir analyser ! »
Bien, nous obtenons des informations très intéressantes ici. Dans un premier temps comme dans le jeu de Go, et beaucoup de courants de pensée asiatiques, le vide compte autant que le plein.
Ici le grand absent est qu’ils ne mentionnent jamais un super Goban avec une ergonomie novatrice ou une nouvelle expérience du jeu de Go en VR ! Le déroulement du jeu en lui-même n’est pas une fonctionnalité clé, il n’est même pas mis en avant.
Le silence de l’équipe produit à ce sujet est éloquent.
Si le déroulement d’une partie de Go ne fait pas partie du problème principal, il en est une sorte de dépendance puisqu’il sert de support aux fonctionnalités clés.
Nous posons tout de même la question et la réponse nous confirme cette déduction.
« Non nous n’avons pas la prétention de révolutionner l’expérience en jeu, au contraire elle n’est qu’accessoire, car dans l’univers du Go nous utilisons le Smart Game Format pour échanger des données. Nous pourrions analyser toute partie qui n’est pas jouée sur la plateforme. La présence d’un Goban n’est qu’une commodité… »
Très intéressant. Finalement le domaine que nous avons identifié en premier est un sous-domaine de soutien. Un espace du problème qui n’est pas critique pour la solution et qui n’est qu’un outil optionnel et remplaçable.
Bon, il nous reste à classifier les autres sous-domaines.
Pour continuer à découvrir et qualifier le domaine il nous faut aussi déterminer les priorités du commanditaire.
Allons à la pêche aux informations en leur demandant dans un premier temps d’ordonner leurs fonctionnalités par ordre de valeur ajoutée.
« Notre numéro 1 est la fonctionnalité d’analyse car elle est la clé de voute de la progression et se distingue vraiment par son ambition »
« Notre numéro 2 c’est l’historisation des statistiques et les indicateurs de progression. C’est un complément pédagogique aux fonctionnalités d’analyse »
« La compatibilité multi-serveur ne vient qu’en numéro 3. Car l’impact pédagogique est moindre. Le support de 2 serveurs majeurs devrait déjà satisfaire une bonne partie de la population de joueurs »
Bien, il semble que le domaine principal de notre système soit davantage celui de l’analyse d’une partie de Go. C’est le problème principal qu’on semble chercher à résoudre, alors qu’au début de notre analyse il n’apparaissait que comme un problème secondaire.
Une dernière question pour la route, vous allez voir c’est marrant :)
Comment le système est il financé, quel est votre modèle économique ?
« Aujourd’hui nous n’avons pas encore bien identifié comment nous pourrions pérenniser le système, nous bénéficions de financements participatifs. Nous ne souhaitons pas que l’accès au service soit payant. Mais nous songeons sérieusement à proposer un service de coaching, en nous appuyant sur les statistiques du joueur et des analyses avancées, nous pourrions proposer un suivi personnalisé avec des conseils pour progresser.»
Ah ! En effet l’avenir du produit dépend aussi du moteur d’analyse. Si il est négligé le projet sera forcément un échec.
Nous avons maintenant une connaissance plus profonde et structurée du domaine du système.
Aujourd’hui notre perception du domaine s’est modifiée radicalement :
Notre plateforme est en fait composée d’un domaine cœur et critique d’analyse.
Analyser ses propres parties en tant que joueur est un facilitateur d’accès à l’analyse. C’est donc un domaine générique moins critique.
Il en va de même pour les domaines « Jouer une partie » et « Compatibilité Serveur ». Ce dernier semble faire partie de l’espace solution, car l’intégration serveur nous fait penser directement au jargon technique. Cependant pour notre client et dans le lexique du domaine cela fait référence à une fonctionnalité du produit recherchée par les joueurs.
Maintenant que nous avons une meilleure compréhension du domaine, nous pouvons prendre des décisions stratégiques :
Notre domaine critique de l’analyse sera notre point de départ et celui que nous devons sécuriser en premier. Nous approfondirons sûrement la modélisation en commençant par ce domaine. Nous mettrons nos meilleurs experts sur la question. Le niveau de qualité attendu dans l’implémentation sera plus élevé.
Le domaine d’historique et de progression bien qu’il fasse partie du cursus pédagogique n’est pas le plus critique. Nos exigences sur cette partie seront moindres dans un premier temps. Nous ne traiterons pas ce sujet en priorité. Il fera l’objet d’une couverture fonctionnelle minime et s’étendra au besoin.
Jouer une partie, n’est qu’une commodité offerte. Nous pourrions juste nous contenter d’intégrer une solution existante, comme WGo.js. Ce qui nous éviterait de gaspiller de précieuses ressources dans le développement et la maintenance.
La compatibilité multi-serveurs n’est pas non plus une priorité. L’interfaçage se veut simple au départ puisque l’objectif est de récupérer les parties jouées pour un joueur. Confier certaines parties de ce sous-domaine à une équipe externe semble envisageable.
Tout ceci doit nous permettre de sécuriser le développement et la direction prise. Ici nous optimisons le time to market sans sacrifier la qualité de notre avantage concurrentiel.
Comme les pierres posées successivement sur le Goban forment l’image finale de la partie. Les domaines que nous avons identifiés vont nous aider à former les relations et les unités livrables du système.
C’est ce que nous aborderons dans la série, lorsque nous étudierons plus le domaine du problème, mais celui de la solution.
Cependant si vous clignez des yeux très vite en regardant le diagramme du domaine vous discernerez les contours vagues de ce que l’on nomme des bounded context.
Dans le jeu de Go les pierres disparaissent, les tensions stratégiques évoluent d’un côté à l’autre du Goban. Il en va de même pour notre domaine qui est amené à évoluer, voir apparaitre de nouveaux domaines et disparaitre d’autres, voir les enjeux évoluer.
Comment jouer au Go sans analyse stratégique ? Comment espérer gagner une partie sans réviser sa stratégie régulièrement pour l’adapter à la situation ? Espérer gagner sur un coup de chance ou une maladresse de l’adversaire ne tend pas vers le Kung Fu (étymologique). Il en va de même pour le design de systèmes. Projetez-vous un peu dans l’analogie !
L’équipe Synbioz.
Libres d’être ensemble.
