Il y a peu de temps je mettais en doute l’efficacité de scrum, sur linkedIn, ici.

Crime de lèse majesté pour beaucoup !

J’ai donc repensé a tout ça, et j’ai essayé de rassembler les dérives souvent constatées dans les équipes scrum.

Ca fait très longtemps que je participe à des équipes scrum, en tant que lead dev, équipier, scrum master, ou PO selon les besoins des clients.

Et les constats de dysfonctionnement que j’ai pu faire sont souvent les mêmes:

1. Les estimations.
   Scrum utilise largement les estimations.
   Or celle ci ne servent strictement à rien. Quelle que soit la méthode, tailles de tee-shirt, story point et consort, au bout d’un moment les Tickets ( car souvent ce sont des ticket et non des User Story ) finissent par avoir tous peu ou prou la même granularité, à une vache près. Dès lors passer du temps à savoir si une story vaut 3 ou 5 points est une pure perte de temps. Ah et souvent par magie, les estimations sont transformées en deadline par simple application d’une règle de trois, très sympa quand il faut expliquer en permanence pourquoi tout ne s’est pas déroulé comme dans le plan.
2. Les sprints sont trop chargés.
   Même si on estime avec application. Même si on fait en sorte de moins charger le sprint ( coucou la loi de Hofstadter ). En conséquence les fonctions livrées sont très souvent incomplètes. Normal, on commence tout pour faire plaisir aux parties prenantes, car on est humain, on veut bien faire, mais on finit jamais rien.
   
3. Les objectifs sont absents.
   Les objectifs métier du sprint sont au mieux flous, ou définis a rebours mais souvent inexistants.
   Normal, sauf coup de bol, le timing du sprint est la plupart du temps incompatible avec la réalisation d’une fonction de bout en bout. C’est soit trop court soit trop long, car fixe.
   
4. Le cadre est trop fixe.
   On fixe à l’avance et à intervalle régulier les réunions de refinement / grooming / chiffrage de user story.
   Et comme les PO vont plus vite à comprendre, que les devs à coder, on fait du stock de User story.  Quoi de plus normal. Les backlogs deviennent ainsi un gros bordel. Il est souvent impossible de s’y retrouver et le taux de story non réalisées ne fait qu’augmenter. Saviez-vous que dans le lean « toyotesque » original, un stock était valorisé au passif d’une entreprise et non à l’actif ? Dit autrement un stock coûte du pognon, et ne rapporte rien. Et votre stock de User Story va vous coûter cher, même si on ne s’en rend pas bien compte.
   
5. La pression monte.
   Comme le pain s’accumule sur la planche, Les devs sont de plus en plus sous pressions « viiiiite il faut avancer, les story s’accumulent !! » et le sprint a tendance à porter de mieux en mieux son nom, car il faut écouler le stock d’US. Bye bye les tâches d’amélioration de fond. Ah et n’essayez pas de « réserver de la bande passante » car, les sprints sont trop chargés, on vous le répète, et une urgence quelconque aura tôt fait de préempter la précieuse bande passante, fût-elle imaginaire.
   
6. Le stock de User Story.
   Les story sont écrites et parfois chiffrées parfois longtemps avant d’être réalisées. Ainsi, au moment de s’y mettre le dev a perdu la moitié du schéma mental du besoin. Si tant est qu’il ai réussi à s’en faire un au moment du grooming. Cette compréhension métier, est pourtant essentielle à la réalisation de sa tâche, afin de prendre les décisions pertinentes, quand lors de la réalisation, il découvrira les cas non-spécifiés. Il y en a toujours. Le stock d’US a un peu moisi, tout le monde a un peu perdu son temps.
   
7. Les devs deviennent des machines.
   Conséquence plus ou moins directe des points 4 et 5, les devs manquent cruellement d’ownership. Transformés en robot stakhanovistes par une méthode qu’on leur ressasse comme miraculeuse mais qui ne peut que les mettre sous pression. J’en ai même vu refuser des tickets si TOUT n’était pas écris, jusqu’aux structures de données à tester. Après quand vous êtes infantilisés au point de devoir demander l’autorisation d’améliorer la qualité logicielle, et que le PO refuse, car il y a plus urgent, ben vous pouvez commencer à vous demander quelle est votre plus value.
   
8. "C'est pas toi le PO ?"
   Le rôle de PO, parlons en tiens. Je n’ai JAMAIS vu de PO. Je dis bien jamais. C’est à dire quelqu’un qui collecte du feedback utilisateur, et qui oriente le produit en fonction. Je n’ai certainement pas eu de chance. J’ai en revanche souvent vu des gens décliner les roadmap managériales, dont moi hein, en rajoutant des petit plus « ce qu’il serait bien de faire ». On fait donc au mieux, avec plus ou moins de réussite. Bah, c’est notre job à plein temps, alors on occupe l’espace, en empilant de la feature, dont l’impact est variable. Mais bon on est payé pour ça 40h semaine, alors on fait et… zou Go To point 3.
   
9. Les epics n'en sont pas vraiment, et rien n'avance.
   Conséquence de tout ça les epics ne sont plus des epics, mais un genre de thème qui sert plus ou moins à essayer de classer les story, pour voir si avec une bonne requête multi critère, on pourrait avoir une idée de quand est-ce que le produit sera fini. Aucune epic ne sera jamais terminée, on ne se choquera plus vraiment 200 epics en cours dans le backlog. Et le produit sera terminé, bah, un jour.
   
10. On perd notre temps au final.
    Et enfin, la méthode est assez lourde et consommatrice de temps. Ce qui fait d’ailleurs souvent lever un sourcil désapprobateur au management. Pour des refinement qui servent à faire du stock, des démos de fonction à moitié faites où tout le monde dort, des rétro qui servent à remonter qu’il n’y a plus de papier toilettes, parce que les 14 rétro précédentes n’ont pas été suivies d’actions concrètes. Et puis on a pas que ça a faire, on 43 tickets à livrer pour après demain.

C’est un peu tout ça que je reproche à scrum, car tout ça arrive même en étant complètement conforme à la méthode.

Alors on pourra me répondre «  non mais tu appliques pas bien la méthode »
Et c’est très possible, j’assume tout à fait ne pas être scrum-certified. Mais encore une fois, dans ces 10 points, j’en ai vu la plupart revenir très souvent. Le hasard à bon dos, mais quand même.

Je commence sérieusement à penser que ces défauts sont inhérents, sinon à la méthode, au moins a la possibilité de l’appliquer au sein d’une organisation plus vaste.

Quand la méthode ne fonctionne pas bien, premier réflexe: plus de méthode !
Plus de réunions, plus de rigueur, contraindre les chiffrages, refuser ci ou ça…. bref, s’arc-bouter en défense. Ça ne marche pas et isole encore plus les devs du reste du monde, pour booster la scro-sainte productivité. Isoler les devs est à mon sens ce qui peut arriver de pire à votre produit.

Bref, Scrum, je t’ai aimé, mais je te quitte.
J’ai trouvé mon nouvel amour.

Kanban.

Mais ceci est une autre histoire.

L'architecture que nous avons mis en place a été largement inspirée par un talk d'Arnaud Lemaire, que vous trouverez ici

Le gars va à fond la caisse dans sa conf et présente un nombre de concept assez hallucinant en 45 minutes, il est d'ailleurs impossible de tout comprendre au premier visionnage.

J'ai donc un peu poncé le machin, et j'ai fais une implémentation à partir de rien, en python, donc, afin de comprendre comment le tout se mettait en musique, l'occasion de repartager tout ça.

Avant de rentrer dans le détail de chaque composant, un grand merci à Arnaud donc, qui grâce a cette conférence ultra dense, nous a permis de nous lancer dans la bonne direction en posant les bases de notre architecture CQRS.  

Objectifs

Les objectif classiques d'une architecture CQRS, sont les suivants:

• Séparation entre lectures et commandes
• la mise en place de Cache pour les lectures
• la mise en place de projection de data pour anticiper les productions de données
• la possibilité de migrer vers de l'event sourcing

Par ailleurs le fait de lister les commandes et le requêtes de notre système va également nous permettre de quitter l'orientation CRUD / ressources qui  a tendance à engluer les systèmes  dans une complexité technique inutile.

Principe de fonctionnements généraux

Une commande va déclencher un traitement, pour changer l'état interne du système. Réserver un billet de train, est une commande par exemple.

Une Query va récupérer de l'information dans le système, par exemple, si on se trouve sur un site de voyage, lister les billets de train que l'on a commandé dans les 6 derniers mois, est une query.

Un Event (évènement) est émis dans le système ou depuis l'extérieur pour avertir d'un changement qui est arrivé.

Chacun de ces objets va donc véhiculer une intention au sein de notre système, pour déclencher des changements d'état ou des récupération d'info.

On peut donc maintenant assez facilement imaginer qu'un point de terminaison API, va uniquement créer une commande ou une query, pour que celle ci soit traitée par notre système.

Schéma de fonctionnement général

Le schéma est divisé en 3 sections, Infra, Application et Domaine, correspondant peu ou prou à de la clean architecture déjà présenté ici.

Les requêtes web arrivent dans la couche de gestion des endpoints, les commandes ou query correspondantes sont envoyées dans le système via les BUS appropriés.

Les BUS de middleware permettent de réaliser tout un tas de traitement transverses comme du log, un pattern Unit Of Work, de l'auth, du contrôle d'accès ou même du cache.

Après avoir traversé le BUS la commande est gérée par un handler, qui va s'appuyer sur la couche domaine pour déclencher les traitements métier.

Le prochain article détaillera le fonctionnement technique de la couche API Endpoint, basé sur Fastapi dans notre cas.

En relisant le blue book, je me suis rendu compte d'une erreur de ma part, enfin, plutôt un oubli, pour être précis. En effet je me suis rappelé que les 3 piliers du Domain Driven Design sont :

• l'approche stratégique
  J'ai commencé à en parler dans les 6 premiers articles, là on est OK.
• l'approche tactique
  ç'est prévu, dans les articles à venir, on est OK aussi là dessus.
• L'ubiquitous langage
  Ah.
  Là on y est pas du tout OK en fait, j'ai carrément zappé cette partie, pourtant ultra importante.  

L'objectif est de définir et de nommer, de manière unique et non ambigüe, les différents concepts et entités de notre application, et surtout de faire en sorte que cete terminologie soit partagée entre toutes les parties prenante du projet.
Vous me direz, "c'est la base", et effectivement, ça l'est.

Ceci étant il n'est pas rare, sur un projet de développement logiciel, que chaque partie prenante nomme les concepts utilisés un peu dans son coin. Cela peut aboutir a des difficultés de compréhension, entre le métier et la technique, voir même à la duplication de terme pour designer un concept, parfois jusque dans le code. Très sympa quand vous galérez déjà à comprendre le métier, que vous vous rendez compte que les fonctions get_x et get_y font en réalité la même chose.

La définition d'un langage partagé, c'est donc l'occasion de mettre en place un glossaire, objectif de cet article donc.
Je triche un peu car comme j'ai déjà développé une version de l'application que l'on se propose d'écrire, j'ai déjà l'ensemble du vocabulaire en tête, mais allons y.

NB: les concepts sont nommés en français, mais le code est en anglais, nous retiendrons donc la traduction entre parenthèse comme référence, ce qui peut donner lieu à des échanges en franglais très jean-claude-vandammien lors des réunions, comme dans tout projet de réalisation informatique.

Equipe (team) :
On va commencer doucement, avec un concept qui parle à tout le monde. Un équipe c'est un groupe de joueur. Jusque là, ça bouscule pas un train de marchandise, on est d'accord.
Une équipe possède aussi de la trésorerie, un encadrement, un nombre de relances, un facteur de popularité.
Une équipe est construite pour participer à une compétition, elle est coachée par un coach. Elle doit respecter des règles de création, et enfin elle est assemblée avec des joueurs dont le nombre et le profil sont définis par un roster.

C'est déjà un poil plus tendu vous aurez noté. Nous allons donc définir tous les termes ci-dessus.

Compétition (competition)
Une compétition, c'est un évènement plus ou moins ponctuel, qui va fournir un cadre de rencontre à différentes équipes. Une compétition est organisée par un club, elle est gérée par un ou plusieurs responsables. Une compétition peut-être une ligue ou un tournoi, la compétition fixe les règles de création des équipes, le mode de calcul des points et des points bonus.

Ligue (league)
Une ligue est un type particulier de compétition, qui se déroule sur une période de temps long, et qui se caractérise par une programmation des matchs. Celle-ci peut-être de type :
- calendrier: toutes les rencontres sont prévues à l'avance dans le cadre des semaines de rencontres
- "open" seules les dates de rencontre sont prévues (ou même pas dans certains cas) et les joueurs présent tirent au sort leur adversaire.

Tournoi (tournament)
Un tournoi est un type particulier de compétition, qui se déroule sur quelques jours max, et dont les appariement sont déterminés au fil de l'eau, en utilisant une méthode de type "ronde suisse".  

Coach (coach)
Afin de ne pas confondre le joueur humain qui joue physiquement à Bloodbowl et le joueur fictif au sein d'une équipe, on désigne par coach, le joueur qui joue à Bloodbowl, et par joueur le joueur en temps que membre d'une équipe de bloodbowl.

Roster (roster)
Une roster contient la définition d'un type d'équipe. Donc le roster désigne l'ensemble des règles, pour un type d'équipe donné, dont:
- la liste et la limite en nombre des types de joueur disponibles pour ce type d'équipe
- le prix des relances d'équipes pour ce type d'équipe
- le groupe de roster de ce type d'équipe
- les champions (star players) qui sont susceptibles de jouer avec ce roster.

Tout ça est un peu détaillé. Donc en résumé nous retiendrons qu'un roster, contient les règles de référence, applicables à la création d'une équipe, quelle que soit la compétition dans laquelle l'équipe va jouer.

Groupe de classement / poule  (ranking group)
Une compétition peut choisir de grouper les équipes au sein de poule, afin de séparer les classements en plusieurs groupes. Le classement d'une équipe au sein d'une competition s'entend donc au sein d'un groupe de classement. Les poules ne jouent que sur les classements, les équipes peuvent toutjours rencontrer toutes les autres équipes d'une compétition, indépendamment des groupes de classement.

Règles de création (creation rules)
Ces règles définissent comment construire son équipe. Il existe, dans le monde de bloodbowl, 26 types d'équipes (roster). Le coach qui souhaite construire une équipe choisi une des 26 possibilités d'équipe, et en fonction

Champion / Starplayer :
Les champions sont des personnages spéciaux qui peuvent intégrer temporairement une équipe, en fonction de la différence de puissance des deux équipes (inducement), afin de réduire les écarts.

Inducement :
L'inducement représente la différence de puissance entre deux équipes, calculée par une grandeur numérique caractéristique de l'équipe: la team value (team value).

Joueur:
Un joueur est un membre (fictif) d'une équipe, il prendra donc part à des matchs. Notion simple à ne pas confondre avec le coach, qui représente le joueur qui joue ces matchs sur table.

Niveau d'expérience :
Le niveau d'expérience d'un joueur représente le nombre d'améliorations qui ont été achetées par ce joueur, via la dépense de SPP (star player points). Le nombre d'amélioration et donc le niveau d'expérience sont au maximum égale à 7.

Points d'expérience / Star player points ou SPP :
Les points d'expérience sont gagnés par les joueurs d'une équipe, lorsqu'ils réalisent certaines action au cours d'un match. Les points d'expérience sont attribués selon un barème qui dépend des actions réalisées, et ce barème doit pouvoir être adapté au sein d'une compétition. Les compétition de type tournoi ne rapportent pas de point d'expérience. Les points d'expériences sont accumulés par chaque joueur, puis dépensés pour acheter des augmentations. Cette logique se rapproche de la gestion d'un compte en banque.

Augmentation de joueur / player upgrade :
L'augmentation d'un joueur vient modifier le profil statistique et / ou les compétences de ce joueur, puis lui attribuer de nouvelles facultées. Les augmentations de joueurs peuvent être gagnées par l'acquisition de point de compétences, ou affectées gratuitement par un commissaire de ligue, dans le cadre d'une modification manuelle de joueur.

Diminution de joueur / player Downgrade :
Ce mécanisme est l'inverse du précédent, et reflète généralement le fait qu'un joueur ait été blessé au cours d'un match. Le joueur en question va donc perdre certaines capacités. Le profil de base du joueur, issue de la ligne de roster qui lui correspond, va donc être modifié par le player downgrade.

Customisation d'équipe :
La customisation d'équipe permet de modifier manuellement, la trésorerie, la popularité, ou les autres grandeurs caractéristiques d'une équipe. Par modification manuelle, on désigne une modification d'une équipe qui n'est pas crée suite à un match. Cette fonction est généralement utilisée pour corriger à postériori une erreur dans le rapport de match.

Customisation de joueur :
Le fait de customiser un joueur revient à modifier sont profil, ses compétences et ou son prix, sans affecter la ligne de roster correspondante. Cela est utile pour prendre en charge des règles spéciales qui pourraient intervenir lors de l'année.

Conclusion

J'aurais pu continuer à égrener les termes métiers, puisque nous avons, je pense, vu a peu près un tiers des notions.
Néanmoins, les notions principales ont été définies, et la valeur de cet article ne se situe pas nécéssairement sur la complétude des informations qu'il contient.
L'objectif était plutôt de souligner l'importance de s'entendre sur les termes, les concepts et les règles métiers qui sont généralement encapsulées dans les termes eux mêmes.
D'ou l'importance cruciale de se comprendre entre parties prenantes, et donc l'importance de ce petit glossaire d'exemple.

Encore un concept que j'ai piqué aux anciens d'Arpinum, JB Dusseault et Arnaud Lemaire. J'espère qu'ils ne m'en voudront pas trop :) D'ailleurs je ne sais pas si ils sont eux même les auteurs de ce concept, Ils nous diront en commentaire, mais quoi qu'il en soit c'est grâce à eux que nous nous sommes familiarisés avec ce concept. Merci les gars !

C'est quoi un monolithe micro-service ready, chef ?

C'est le canada-dry du micro-service. Ça en a le goût, ça en a l'odeur... mais ça n'en est pas.
En gros on garde un découpage en module logique isolés (nos bounded contexts), mais au lieu de dispatcher ces modules sur des processus ou des machines séparés, on garde tout ça au sein d'une seule application, sur un seul processus. Voir un seul thread, si on est en python... oui bon on fait ce qu'on peut.

Donc on fait "comme si" on avait des micro-services, d'un point de vue de l'architecture logique, mais on garde une architecture physique unique. Ça permet de bénéficier des avantages de la maintenabilité liée à la mise en place d'unité logique très découpées, sans avoir à se tarter de l'asynchronisme, de la com' réseau, de la tolérance aux pannes, de l'orchestration, du kubernetes et tout un tas de joyeuseté qui n'apportent pas forcément grand chose.
Ce n'est jamais vraiment évident de savoir jusqu'ou aller, en particulier sur ces sujets de gestion thread / processus. Doit-on utiliser des brokers de message pour communiquer entre nos bounded contexts ? doit on-séparer la configuration de la persistence pour chacun de nos contextes ? donc faire en sorte que chaque brique logicielle ait sa propre configuration de base de données... Ce faisant on se rapprochait beaucoup d'une architecture micro-services, et la complexité obligatoire qui en résultait nous a paru largement overkill dans un premier temps.

Temps qui peut d'ailleurs durer, avant que votre application ait vraiment besoin de passer à l'échelle. Genre, jamais pour un bon 95% des appli B2B, à mon avis.
Donc schématiquement notre appli ressemble à ça :

Le contenu des blocs va être calqué sur notre analyse stratégique, pour que chacun de nos blocs corresponde à un Bounded Contexte tel que nous les avons définis dans l'article précédent.

Les grand principes

Ok, maintenant qu'on a dit ça, on est pas plus avancé. Donc lorsque l'on a pensé l'architecture de notre système, nous avons utilisé un ensemble de règles simples pour nous aider à décider lorsque nous étions dans le flou :

• Multiple briques
  L'application sera composé de plusieurs bounded contexts, isolés les uns des autres. Chaque Bounded Context dans un répertoire dédié, mais surtout il est évidemment interdit d'importer ou de faire référence à des objets externes depuis un bounded context donné.
  En gros ce qu'on veut éviter ce sont des importations crado entre bounded context, qui viendraient coupler fortement nos contextes. C'est tout con, mais dans presque tous les projets django que j'ai croisé, ce principe  n'était pas du tout respecté, entrainant des dépendances fortes entre les apps du projet.
• Réutilisabilité
  Par conséquent, chaque bounded context doit dans l'absolu pouvoir être complètement "décroché" de l'application pour être réutilisé directement dans une autre application, si tant est que la nouvelle application fonctionne sur les mêmes principes d'infra que l'appli initiale. Cela nous permet de trancher sur les limites d'influence de tel ou tel contexte. Cela signifie aussi que chaque bounded context doit être en mesure de gèrer ses points d'entrée. Donc la fourniture des endpoints d'api, de manière autonome et namespacé.
• CQRS / CQRS-ES / CRUD
  Chaque Bounded Context sera potentiellement architecturé selon des principes différents. Par défaut nous utiliserons une architecture CQRS, que nous détaillerons dans un futur article.
  Nous opterons pour le CQRS + Event Sourcing, dans le cas ou la dimension temporelle du stockage apporte un plus. Les évolutions de joueurs et d'équipes seront un excellent cas d'usage pour l'Event Sourcing. Enfin le CRUD sera réservé aux contextes qui gère un stockage naïf, genre le moteur de blog, embarqué dans le contexte communication.                                                      
• Onion / Clean Architecture
  Chaque Bounded contexte est organisé en interne en suivant les principes de l'architecture en couche pour la gestion du métier. L'architecture en couche, ou clean architecture chez Uncle Bob. Pour mémoire une architecture en couche se décompose en 3,4 couches ( 3 chez nous ) et suit le schéma théorique ci-dessous :

Nous avons donc organisé notre code en trois couches :

• Infrastructure :
  La couche de plus haut niveau, en charge à la fois de la gestion des requêtes web entrante, de l'intéraction avec une ligne de commande, de la persistance des données et éventuellement de leur serialisation pour envoi sur le réseau.
• Application :
  C'est dans cette couche que nos cas d'utilisation doivent apparaître. Nous aurons par exemple un fichier start_user_signup.py dans cette couche. Nous verrons ensuite ce que nous mettons dans ce fichier.
• Domain :
  C'est enfin ici que vient se loger tout le métier de notre application. Le métier est modélisé par une structure de classe et de méthodes python, qui n'ont aucune dépendance avec quoi que ce soit d'autre. Nous utilisons une règle simple pour notre code métier : Le product owner doit pouvoir lire le code et comprendre ce qui s'y passe. C'est cette règle toute conne qui va nous guider dans l'écriture de notre métier. C'est cette règle qui va permettre de nommer correctement nos entités, nos aggrégats et nos value objects. Concepts sur lesquels nous reviendrons.

De plus la règle fondamentale d'une architecture en couche est simple, une couche interne ne peux jamais dépendre d'une couche de niveau supérieure. Donc par exemple, la couche application ne peut jamais importer quoi que ce soit de la couche infrastructure. La couche Domain elle ne doit rien importer à part les libs de base du langage.

Ceci étant, en vrai, pour le moment on a pas besoin de tout ça. C'est un réflexe de partir en concevant une apli avec tout se bordel, mais on en a pas besoin, pour le moment.

Ce dont on a besoin c'est de code qui tourne, et qui fait des choses.
On appelle ça du code métier.
Et le code métier il va dans la couche domaine.
Donc.... ben on va commencer à écrire du code métier. On verra plus tard ou est-ce qu'il doit tourner, comment sont stocker ses états et tout ça.
pour le moment: on code.

Bounded Context is a central pattern in Domain-Driven Design. It is the focus of DDD's strategic design section which is all about dealing with large models and teams. DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships.
Martin Fowler.

Identifier les contextes métier - bounded contexts

Dans l'article précédent, nous avons aboutit à la création d'une cartographie des domaines métier.

Nous allons maintenant voir comment passer de cette modélisation de domaine, à une proposition de modélisation d'architecture logicielle. Donc en quelque sortes, comment passer de la modélisation du problème à la modélisation de la solution.

L'identification de ces contextes métier est issue du regroupement de processus  liés entre eux. L'architecture logicielle cible doit donc nous permettre de répliquer cette organisation métier, dans le code. Nous allons donc designer une architecture qui fait la part belle aux "modules" métier. C'est a dire à des "paquets" fonctionnellement cohérent, et dont l'action se borne à un aspect du cycle de vie de nos processus. C'est ce que le Domain Driven Design appelle le "bounded context" ou contexte d'utilisation.

Et là en toute logique vous allez me dire, "ouais ben super je fais un contexte 'équipe' et je mets tout dedans".

Alors oui,

mais non.

Déjà cela ne sera pas super cohérent avec notre cartographie métier, donc non.
Mais raisonnons par l'absurde, et mettons que l'on modélise une équipe dans son entièreté, avec toutes ses responsabilités, dans un seul module orienté entité. Donc in fine, dans une seule bonne grosse classe.
Pensez-vous que nous allons avoir besoin de toutes les données de la classe tout le temps ?
Question con hein, mais pensez vous que la notion d'équipe affichée dans un tableau de classement, soit la même que la notion d'équipe utilisée dans un rapport de match ?
Dans le premier cas vous allez avoir besoin du nom, du logo de l'équipe, de son coach et des ses point de classement.
Dans le second cas, les points de classement ne vous servent à rien, en revanche il vous la liste des joueurs, leur niveau d'expérience, savoir si ils ont été blessés si ils ont participé au match...
Donc ces deux "facettes" de la notion d'équipe, n'ont en réalité rien à voir l'une avec l'autre, selon le contexte dans lequel on manipule la notion. Si on vient les lier dans l'implémentation, on va passer notre temps à se trimballer des données, dont on ne sert que partiellement. Et ça ralentit toute la machine, à la fois en Run mais aussi en Build, car les structures deviennent trop volumineuse.
Il est donc nécéssaire de dissocier ces deux facettes, et de ranger chaque déclaration a sa place, dans le répertoire qui vient modéliser le contexte d'exécution: le fameux bounded contexte.

C'est pas plus compliqué que ça.

En revanche c'est ultra contre intuitif et c'est aussi un peu l'inverse de ce que l'on nous enseigne à l'école : modéliser une entité avec toutes se responsabilité, pour surtout ne pas se répéter, le fameux principe Don't Repeat Yourself - DRY. C'est ce principe DRY à qui il est obligatoire de dire au revoir, pour le bien de notre architecture, dans une certaine mesure.

Et d'un coup d'un seul deux phénomènes vont apparaître :

• une simplification drastique à l'échelle locale
• une complexification non moins drastique à l'échelle de l'architecture de l'application

Mais nous verrons ça quand nous seront dans le code, dans le prochain article, et nous aurons largement le temps d'explorer plus en détails la construction interne d'un Bounded Context, en tant que composant logiciel de notre application.

Nos bounded contextes, et l'approche "Model it wrong"

Cet article à pris davantage de temps à écrire que les autres, pour plusieurs raisons, dont la principale est la peur de se tromper.

En effet j'ai mené une première analyse qui aboutit au schéma ci-dessus, une première version de ce qu'on appelle une contexte map, mais que se passe-t-il si les bounded context identifiés ne sont pas les bons ? il faudra nécessairement retoucher cette map, pour que tout soit bien propre dans l'article, afin de ne pas passer pour un charlot.
Et quelle garantie ai-je à ce stade que ma modélisation est la bonne ? Carrément aucune.

C'est encore un point relativement paralysant dans l'approche DDD. On n'est pas sûr de faire "juste".
Ce que l'on doit apprendre ici, c'est que "juste" est en réalité une notion qui n'existe pas en DDD. Il y a des modélisations qui fonctionnent, et d'autre qui fonctionnent moins bien, mais nous ne savons pas, au moment ou l'on démarre un projet dans quel cas nous nous trouvons. Nous sommes donc bien avancés !

Donc je ne sais pas si la modélisation actuelle de la solution est pertinente, ou non. Et ce n'est pas forcément grave.

Ce qui compte c'est de démarrer. Notre modélisation est forcément fausse, au moins dans une certaine mesure à l'étape ou nous en sommes. Nous avons juste employé des techniques de modélisation du problème qui nous permettent de ne pas faire trop faux, dans une première approche.

C'est comme ça que nous avons envisagé la méthode "Model It Wrong".

Nous jugerons de la pertinence de notre découpage au fur et à mesure de l'implémentation. Si nous sommes amené à faire rentrer trop de responsabilités dans un contexte, ou si certaines entités deviennent pénible à manipuler, c'est le signe que notre granularité est trop importante, et qu'une session de découpage doit être menée, afin sans doute de diviser un bounded context en deux.

Finalement la liste des bounded contextes

Faire la liste complète des bounded contexts, dont TOUTE l'application aura besoin,  va être un exercice fastidieux et inutile à ce stade (déjà parce que nous ne savons pas bien quelles sont les fonctions métier qui vont être couverte in fine par notre appli).
Partons donc avec un premier objectif simple en tête. Cet objectif va nous permettre de rester dans un périmètre raisonnable, et donc de poser l'environnement technique de notre projet DDD.

Nous allons donc, dans un premier temps offrir à nos utilisateurs de :

• Créer un compte, vérifié par email pour accéder à tout le contenu de la plateforme
• Créer une équipe
• Inscrire cette équipe à une ligue (qui aura été préalablement crée par un commissaire de ligue )

Pour pouvoir enchainer ces simples étapes, nous allons avoir besoin de la liste des contextes ci-dessous.

Access:
Le context qui va gérer les droits d'accès et de visualisation au sein de la plateforme. C'est ce contexte qui va contenir les fonctions de login ou de création de compte par exemple. Le domaine Onboarding va s'appuyer sur les fonctions du contexte Access. Je ne suis pas complètement sûr du bien fondé de la présence de ce contexte, un peu trop technique à mon goût, mais partons avec et nous verrons bien si sa présence est nécessaire au fil de l'eau.

Communication :
La fonction naïve est de pouvoir écrire des articles sur la plateforme. On se doute déjà que le métier embarqué dans ce contexte va pas être foufou. Nous allons plutôt être sur (comme disent les agents immobiliers) sur un contexte full CRUD.

TeamRegistration :
L'objectif est ici de permettre aux futurs coach de créer et d'inscrire leurs équipes à une saison, d'une ligue, d'un club. Déjà là il y a beaucoup plus de notions métier. Et il n'est pas du tout garantit que toutes ces notions métiers doivent êtres gérées au sein du contexe TeamRegistration.
- une équipe : créer et inscrire une équipe semble le coeur de la fonctionnalité de ce domaine, donc ok, les entités "équipe" et inscriptions devraient bien être gérées ici
- un club / une ligue / une saison : Ces notions, simples à appréhender, n'ont à priori aucunes raisons d'être gérées complètement par le contexte team registration. Il paraît plus juste que ces notions qui soient gérées par un contexte de création / enregistrement de ligues et de clubs, dédié à cet objectif. Donc le domaine team and clubs devrait en quelque sorte s'abonner aux évènements de gestion qui interviennent dans le domaines LeaguesAndClubRegistration. Un premier cas de communication entre bounded contexts sans doute.

Ceci étant, pour pouvoir créer une team, nous allons également devoir nous appuyer sur les règles du jeu, pour créer des équipes valides. Donc quelque part le contexte RuleRepository devra aussi nous envoyer des infos.

LeaguesAndClubRegistration :

Comme on en a besoin pour créer une équipe, créons donc le contexte qui permet de gérer le cycle de vie des clubs, ligues, saison de compétition. D'ailleurs si on réfléchit cinq minutes, lorsque un de nous utilisateur va créer une ligue, ne va-t-il pas avoir besoin de plus que clubs et ligue ? des règles de départ par exemple, puis des règles de calcul de classement, des définitions de poule également.
Doit on créer un contexte pour ces entités ?
Bonne question, et je ne suis pas sûr qu'il y ait de mauvaises réponses à cette question. Disons que oui, et nous verrons si ce choix est justifié.

RankingRulesCreation :

Ce domaine va nous permettre de créer des règles de calcul de classement. La manière dont nous allons permettre à l'utilisateur de faire ses propres règles ne sera à mon avis pas triviale du tout.

RulesRepository :

La notion de règles rejoint celle de référence. En tout cas dans le jeu qui nous concerne. Telle équipe peut avoir tel et tel joueur, en telle quantité... ce genre de chose. Sachant que nous avons environ 120 à 150 profils de joueurs, répartis en environ 25 types d'équipes différentes, pour vous donner une idée.

Ceci évidemment sans compter les Star players, et les types d'équipes (que l'on appellera roster dans la suite) non-officiels, auquels viennent parfois s'ajouter les roster et joueurs "maisons" c'est a dire inventés par certains coachs, pour certaines ligues seulement.

Donc quand on parle de règle, il s'agit davantage de référentiel que de règles métier en tant que telle.

Ouf !

Bon normalement avec les contextes définis ici, nous devrions être en mesure de pouvoir remplir nos premiers objectifs métier. C'est à dire que, logiquement, nous avons définit les structures en charge de gérer les cylces de vie et les actions métiers que nous allons appliquer sur nos premières entités.

En revanche, pour faire ça, il va nous falloir poser TOUTE la tripaille technique. Il nous faut donc nous appuyer sur un cadre technique qui va supporter au mieux l'expresssion du métier identifié.

Les développeurs vont donc trouver davantage leur compte dans la série d'article qui suit: Le DDD Tactique - la mise en place de l'architecture globale et particulière.

Si nous résumons la démarche stratégique, nous avons jusqu'à présent :
#2: posé le plan de bataille
#3: identifié les acteurs de notre domaine
#4: décortiqué les processus métiers de notre domaine

Nous allons donc maintenant essayer de regrouper nos différent processus et sous-processus en sous-domaines métier cohérents. Pour mémoire, le domaine métier auquel nous souhaitons nous adresser, est celui de la gestion d'un club de jeu. Domaine qui en vaut un autre, et qui est assez facile à se représenter pour un lecteur occasionnel.

NB :  Encore une fois, la démarche proposé au fil de ces articles n'a pas d'autre valeur que celle d'un retour d'expérience, ce n'est ni un cours, ni une injonction à suivre quoi que ce soit. Il s'agit juste d'expliquer comment nous nous y sommes pris pour adresser une problématique Domain Driven Design, depuis le début, jusqu'à la livraison.

Rappel de la liste des processus

Lors de l'article précédent, nous avons donc utilisé le story mapping, pour arriver à une définition de processus, orientée acteurs, dont le résultat est rappelé ci-dessous :

Il est donc l'heure de dessiner des patatoïdes afin de regrouper ensemble les cartes qui méritent de l'être.

Il est assez évident de faire un sous-domaine métier regroupant l'ensemble des fonctions de communication entre les parties.

Le processus de définition initial semble intéressant a traiter isolément, car c'est ici que tout va démarrer, et c'est également ici, que des choix impactant le déroulement de nos processus ultérieur va se faire.

L'organisation au préalable va sans doute être liée, d'une manière ou d'une autre au domaine précédent.

Cette activité commence à approcher du coeur du réacteur de notre proposition : automatiser la gestion d'une ligue.

Cette partie est la suite de la précédente. Il est d'ailleurs légitime de se poser la question de pourquoi nous avons choisi de la détacher de la précédente. A priori le fait de consigner correctement les évènements de match, nous a semblé une étape et des enjeux différents de réaliser les calculs liés aux matchs en question.

Il s'agit ici de prendre en charge les impacts des calculs réalisés dans les rapport de matchs. L'avenir dira si oui ou non la séparation était nécéssaire.

La suite logique de la saisie d'un match, c'est l'évolution du classement, et l'évolution des équipes comme vu ci-dessous.

L'ensemble de ces domaines nous permet de construire la carte de sous-domaines ci-dessous :  

Generic, Supporting, ou Core Subdomain

Chaque sous domaine n'apporte pas la même chose à notre proposition de valeur. Ils n'ont pas le même outcome comme dirait Jean-Claude Van Damme.

Le domain Driven Design propose de classer ces domaines en trois grandes catégories :

- Generic : La commodité, ce par quoi nous devons passer pour faire fonctionner l'ensemble mais qui est déjà tellement répandu que cela n'apporte plus grand chose en terme de différenciation. L'exemple classique c'est le système de paiement. Lorsque l'on met en place un site ecommerce, il serait idiot de redevelopper depuis zéro un système de paiement. Et pourtant, sans système de paiement, le système ne fonctionne pas. Le paiement est donc un passage obligé, sans grande valeur ajoutée.

- Core : L'autre bout du spectre, là on est dans le spécifique métier pur, les fonctions qui vont nous permettre d'apporter une nouvelle proposition sur un marché, là ou une techno révolutionnaire change la donne, bref,, le coeur du réacteur de notre proposition. C'est évidemment sur cette partie qu'il faudra concentrer les effort de développement, d'UX, de tout en fait. Pour notre exemple c'est la gestion des rapport de macth et les calculs associés qui nous permettrons de changer la vie de nos utilisateurs.

- Supporting :
On est entre les deux. Pas complètement de l'ordre de la commodité, mais pas nous plus complètement au centre de toutes les attentions. En général classer les domaines selon les deux typologies précédentes est assez évidentes, et pour ceux qui restent, il y a le supporting domain. La stratégie de réalisation des domaines du supporting modèles va être assez variable selon les contextes. Pour notre exemple, les fonctions de communication pourraient être considérées comme du supporting, car elles sont nombreuses et au centre de pas mal d'échanges entre les coach et le commissaire de ligue, mais techniquement les moyens de communication sont plutôt de l'ordre de la commodité.

Si l'on classe nos domaines selon les 3 catégories ci dessus, on obtiendrait :

Maintenant qu'une première modélisation du domaine est posée, nous allons voir comment proposer un découpage fonctionnel qui permet de répondre à nos problématiques, en appliquant une organisation aussi mirroir que possible, et en ajoutant peut-être certaines préoccupation purement techniques.

La suite se trouve à l'article #6 L'apparition des bounded contexts

L'article 3 nous a permis de commencer à nous familiariser avec le domaine, en définissant les acteurs, et leurs besoins. L'étape suivante pourrait être de voir comment leur besoins prennent forme, à l'heure actuelle. Rentrer dans le détail d'un processus permet de mettre à nu le dit processus, et donc d'en comprendre tous les rouages. Et ça c'est top pour notre compréhension de ce qui se passe avant que l'on commence à intervenir, en sommes comment est organisé le fameux problème.

Détailler les processus

Pour rentrer dans ce niveau de détail, il nous faut échanger. Echanger cette fois ci de manière un peu plus organisée, au travers d'atelier de définition. Il existe énormément de façons d'organiser un échange pour modéliser un processus, des plus ou moins bonnes. Il y en a surtout une mauvaise.

La mauvaise c'est le cahier des charges.

Un bon gros cahier des charges de 200 pages, qui décrit en détail la couleur de fond du bouton de l'écran 12, mais qui ne donne aucune compréhension étendue du domaine, et surtout un cahier des charges c'est focalisé vers la solution, pas sur le problème. Le truc est donc aussi utile à un dev qu'un  soutient-gorge à une enclume.

Bref depuis quelques années et l'apparition du design thinking, on voit apparaître des modes d'échange et d'idéation basé sur des ateliers collaboratifs. Alors certes tout dans le design thinking n'est pas a garder, mais certaines méthodes sont redoutablement efficace pour transmettre une vision. Les trois techniques d'échanges les plus à la mode à l'heure actuelle sont listées ci-dessous. En revanche j'avoue humblement ne pas être un expert de l'event storming, ou du domain story telling. Du story mapping, un peu plus déjà.

Le story mapping
Cette technique fait un peu figure de doyenne, et existe depuis 2014 (c'est quand même incroyablement récent...). Le bouquin de référence est celui de Jeff Patton, dispo en français. La méthode a été présenté de manière parfaite par Alexandre Boutin dans une conf dédiée en 2015. Personnellement, et jusqu'à présent, c'est ma technique préférée pour discuter du besoin avec un client ou un expert du domaine. Je la trouve naturelle et très souple. Bien que cette souplesse puisse conduire a des ateliers improductifs si on se concentre sur la technique davantage que sur les problèmes, ou les parcours de l'utilisateur. Le story mapping, c'est vraiement comme un story-board de production vidéo, on découpe les processus par étapes, tant qu'on ne comprend pas exactement ce qu'il y a dans une étape, et une fois que c'est clair on passe à la suite. Cette souplesse en fait un moyen idéal d'échange et de modélisation des processus, dans l'espace du problème pour comprendre le fonctionnement actuel, ou dans l'espace de solution pour imaginer comment va fonctionner notre plate-forme demain.

L'event Storming
Inventé récemment par Alebrto Brandolini, internet regorge de ressources sur le sujet, je vous laisse faire vos propres recherches. De mon point de vue cette méthode est intéressante, mais je trouve l'approche trop technique, et pour certains profils qui ne seraient pas à mon avis capable du niveau d'abstraction nécéssaire. Bref pour moi, cela n'est pas assez orienté client, et trop orienté sur le besoin des devs.

Le domain story Telling
Le petit nouveau des techniques d'interview. Je trouve ça hyper intéressant mais un peu verbeux, et peu lent. et de ce que j'ai pu voir la technique révèle son plein potentiel à une échelle un peu en dessous de la stratégie. Plus efficace donc pour modéliser le détail d'un scénario d'usage, qu'un ensemble de parcours client. A utiliser dans un second temps, pour moi.

Bref tout ça n'est que mon avis évidemment, et se discute totalement. Pour avancer, j'ai donc organisé un story mapping, dont voici le résultat.

Disclaimer: comme tout le reste, un story mapping est valide à un instant T, et devrait donc évoluer avec le temps. Avec le temps la solution s'affine, ouvre d'autre perspectives, le contexte du projet évolue... bref, s'adapter au contexte est un peu obligatoire, mais le story mapping nous donne déjà des infos sur la direction dans laquelle partir.

Le pitch de l'atelier

Cadrer un atelier d'échange est hyper important. L'introduction que j'utilise est généralement "Nous allons décrire ensemble les étape que vous franchissez aujourd'hui pour faire votre métier" Cela permet aux expert de nous livrer la nature des tâches que nos intervenant réalisent, sans se focaliser sur les outils qui sont en jeu. C'est le but du jeu : comprendre ce qu'ils font, et pourquoi ils le font. Surtout pas comment. Si on tombe dans le comment on risque de se focaliser sur la solution que l'on imagine, et nous n'en sommes pas encore là.

Le story mapping par acteur

En partant des besoins primaires listés à l'étape 3, nous avons construit les User Map ci dessous :

Le Coach :

Nous avons donc au passage ajouté quelques besoin qui n'étaient pas listés dans l'article 3.

Le Commissaire de ligue

Evidemment cette partie est beaucoup plus fournie. Le commissaire de ligue est notre cible principale, c'est à lui que nous allons rendre service au final, et c'est lui qui est en charge de davantage de tâches.

Je pense pas qu'il soit nécéssaire de présenter en détail le contenu des cartes, en toute logique elles sont suffisamment parlantes, que ça soit pour la partie coach ou pour la partie commissaire de ligue.

Maintenant que nous avons identifié une première version des parcours client, l'étape suivante va être de regrouper ces parcours, sémantiquement parlant en domaine cohérents. Nous aurons ensuite davantage de facilité à proposer une solution, elle aussi découpée en contextes. Nous approcheront ainsi la définition de nos contextes d'utilisations, ou bounded contexts.

C'est objectif de l'article #5: Définir les domaines et sous-domaines

Ou essayer de savoir un peu dans quelle direction se diriger, en première approximation.

Collecter le savoir et définir le langage

Lorsque l'on démarre un projet de réalisation logicielle, la première partie, c'est de comprendre le besoin. C'est un peu enfoncer une porte ouverte me direz vous. Mais cette compréhension mutuelle va constituer les fondations de toute la suite.

L'objectif de cette étape est donc double :
- transmettre une première connaissance métier aux développeurs
- définir le langage que l'on va utiliser dans la suite du projet.

Transmettre le problème
Au démarrage, nous ne sommes pas encore, au moment ou je vous parle, capable d'apporter une solution, pour une raison simple :  nous ne connaissons pas le problème métier à résoudre.
Les discussions avec nos experts vont donc avoir pour but d'aider les équipes d'ingénierie a cerner le problème. Lorsque nous aurons listé les acteurs et leurs "pain-points", ce qu'ils font aujourd'hui, nous seront davantage en mesure de proposer une solution.

Adopter un langage
Ce langage, ou Ubiquitous Language dans la langue de Kanye West, permet de nommer de manière non ambigüe les actions et entités de notre domaine métier. Cette phase est également cruciale, car savoir nommer ce dont on parle est juste la base pour assurer la compréhension des parties lors de tout le projet.
Une des techniques pour susciter l'adoption est d'être vous même irréprochable sur l'emploi des termes. Quitte a reprendre l'interlocuteur, lors de l'emploi d'un mauvais terme, si vous le détectez. Au bout d'un certain temps la pratique diffuse, et l'adoption se fait.

En revanche, un conseil, attention a ne pas pêcher par orgueil en voulant réinventer le vocabulaire métier. C'est surtout à nous, développeurs, d'aller vers le client en adoptant son langage, autant que faire ce peut, en supprimant les synonymes ou les notions ambigües. Ce n'est pas forcément simple, mais c'est obligatoire.

Les acteurs de notre domaine

Quels sont les grand type d'intervenants dans l'organisation et le suivi d'une compétition ?

• Le coach :
  Le gars ( ou la meuf ) qui participe à une ligue ou un tournoi. Pour mémoire, la ligue c'est un match par mois avec les équipes qui progressent au fil du temps, un tournoi c'est 5 match en un week-end, sans que les équipes ne progressent.
  
• Le commissaire de ligue :
  Le chef d'une ligue. Celui qui organise les journées de rencontre, qui saisit les rapports de matchs pour que les équipes progressent, qui motive les joueurs à venir effectivement jouer leur match pour que la compétition progresse. Les commissaires de ligue sont évidemment également des coachs dans 95% du temps.

Les besoins de nos acteurs

Et que font ils ces braves gens ?

Le coach :
Lui est là en consommateur.
- Il vient aux soirées de jeu, quand il y pense ou quand son commissaire lui rappelle.
- Il joue ses matchs, et notes ses actions sur une feuille de match. Ces actions rapporteront de l'expérience à son équipe, qui deviendra plus forte. Il note aussi les blessures que son équipe à infligé à l'équipe d'en face. Qui par conséquent deviendra moins forte, à cause des dites blessures.
- a la fin du match il donne la feuille de match a son commissaire de ligue.
- quand son équipe a été mise à jour par le commissaire, il va regarder quand est la prochaine journée de ligue, et contre qui il joue, si l'info est disponible. Il regardera aussi son classement pour voir si il a des chances de remporter la ligue cette année.

Le commissaire de ligue :
Il organise un peu tout le bastringue.
- il bat le rappel pour la prochaine journée, pour que tout le monde soit là
- il joue son match comme les autres coach
- il collecte les feuilles de matchs en fin de journée
- il fait évoluer chaque équipe en fonction de chaque action ou blessure de chaque match.
- il prévient les joueurs que les équipes sont a jour, et leur demande de vérifier que tout est OK
- il corrige les erreurs contenues dans les feuilles de match en les modifiant
- il met à jour le classement

Le métier de commissaire de ligue est une plaie.

Quoi qu'il en soit nous connaissons désormais les activités de nos acteurs, dans le domaine qui nous intéresse. Ces activités sont essentiellement manuelle. Par exemple le fait de battre le rappel consiste à envoyer des sms, des messages sur des forum ou sur whatsapp. La saisie de feuille de match est même parfois réalisée via excel, avant que tout ne soit calculé à la mano, pour finalement que les nouvelles versions d'équipe ne soient envoyées par mail en version PDF. Si il y a beaucoup de joueurs, cela peut prendre un temps conséquent, plusieurs heures.

La prochaine étape va donc être d'imaginer comment nous allons modéliser les parcours clients de nos acteurs, au sein d'une solution qui leur simplifierait l'existence. L'exercice est assez fun, puisqu'à ce stade l'imagination sera notre seule limite.

C'est l'article #4 qui traite de ce sujet.

Le DDD regroupe tellement de recettes que c'est assez compliqué d'identifier un bout par lequel débuter, lorsqu'on veut s'y essayer.

Classiquement le Domain Driven Design propose deux niveaux d'action :la stratégie et la tactique. La stratégie pour la vue de haut et la tactique pour les détails, en résumé.

Phase Stratégique : L'objectif est de cerner le problème auquel on s'attaque. Donc de permettre aux développeurs de comprendre les enjeux, les entités, les problématiques... bref l'univers auquel on s'adresse. Phase assez cruciale, mais aussi un peu intimidante car il est très rare que l'on comprenne intégralement et rapidement les enjeux de la digitalisation de processus complexes. Cette phase est classiquement supportée par des méthodes et des ateliers qui visent a discuter avec les experts du domaine pour s'approprier une partie de leur savoir.

Phase Tactique: Ici, les devs sont davantage en zone de confort, car on parle technique. Les patterns tactiques regroupent un ensemble de bonne pratiques de code, pour réaliser notre implémentation DDD. Ces bonnes pratiques visent à assurer que la modélisation stratégique du problème faite préalablement ne va pas se retrouver noyée au milieu d'enjeux purement techniques et exogènes à notre problématique métier.

Et il y a évidemment une boucle de rétro-action entre ces phases. Nous allons définir une première approche stratégique, puis en faire une implémentation. C'est lors de leur de l'implémentation que nous allons nous confronter aux limites de pertinence de notre première approche stratégique.

Donc nous allons potentiellement redécouper, et réagencer les domaines. et modifier le code en fonction. On va essayer de ne pas faire ça trop trop souvent histoire de ne pas cramer tout le temps en refacto mais bon vous voyez l'idée.

Le plus naturel pour notre gestionnaire de ligue de football fantastique est de commencer par l'aspect stratégique. En gros essayer d'avoir une vue d'avion de notre sujet. Essayer de capturer la problématique d'ensemble.

Cette partie est détaillée dans l'article suivant, en commencant par identifier les acteurs de notre domaine.

Ensuite nous verrons quels sont les moyens d'implémentation que nous avons choisi pour traiter nos problématiques.
La route est encore longue avant d'avoir une appli qui tourne.

Tous les principes d'architecture logicielle paraîssent toujours lumineux quand ils sont expliqués. En gros tout est toujours merveilleux dans le meilleurs des mondes.

Ce type d'explication est souvent stérile car sans cas d'application il est difficile de saisir les détails ou les limites des principes en question.

Pour éprouver notre approche du DDD, nous avons un peu tout essayé. Des ateliers, des conférences, des webinairs... mais a'ment donné, pour faire du cheval, il faut monter sur un cheval.
Nous avons donc du implémenter un cas reél, issu d'un besoin existant, en DDD, sur une archi mixte CRUD / CQRS / Event sourcing.

Toutefois, nous ne pouvions pas prendre le risque d'essayer des pattern et des architectures nouvelles sur un projet client. Les clients sont là pour être servis le plus efficacement possible, pas pour nous payer une formation.
Par ailleurs nous n'aurions pas pu dévoiler des détails d'implémentation d'un projet client, pour des raisons évidentes de confidentialité. Et ce retour d'expérience nous paraîssait intéressant, car nous n'avions rien trouvé d'équivalent.

Nous avons donc pris la décision de mettre notre démarche DDD à l'épreuve des balles sur un projet side. Un projet non-commercial, qui n'aurait pas d'autre but que de servir ses utilisateurs gratuitement, et d'aiguiser notre connaissance en DDD donc.

Nous aurons ainsi tout le loisir de détailler notre architecture, notre démarche de modélisation tactique et stratégique, afin de donner du corps à l'ensemble, et donc de tester tous nos choix à l'aune d'un cas réél, sans pour autant mettre qui que ce soit en porte-à-faux.

L'objectif métier

L'application Roxana est destinée à gérer des ligues et des tournois d'un jeu de plateau. Un jeu que les plus geeks (et les plus vieux) d'entre vous connaissent peut-être déjà :

Bloodbowl

Le jeu de football US fantastique édité par GameS Workshop depuis 40 ans environ.

Ce jeu met en scène deux équipes qui s'affrontent dans un match qui s'approche du foot américain, en un poil plus violent et un poil plus fourbe.
Il y a donc dans la vie réélle des clubs de gens qui se réunissent pour jouer des matchs de bloodbowl sur un plateau, un peu comme ou joue aux dames ou aux échecs.

A l'issue d'un match les équipes ont progressé, les joueurs ont potentiellement encaissé des blessures. Elles ont également amassé de l'or en fonction de l'affluence. Ce pognon permettra d'acheter de nouveaux joueurs, ou du staff qui donnera des bonus lors du prochain match. Rien de bien compliqué, quoi que.

Cette gestion de l'évolution des équipes est relativement fastidieuse car bardé de calculs... et de règles métier.  J'ai donc crée il y a quelques années un site qui permettait d'automatiser toute cette phase, ainsi que le calcul des points de classement de chaque équipe. Passage obligé pour savoir en fin de saison qui a décroché le titre tant convoité de champion de bloodbowl de Saint Simon De Pelouaille.

Le site en question est vieillissant, nous avons donc décider d'en réécrire une version, en appliquant l'ensemble des patterns du DDD, pour réaliser un objectif concret.

Cet objectif présente beaucoup d'avantages :

• les règles de gestion d'une ligue et des progression des équipes sont relativement complexes, ce qui nous donne des cas d'usage suffisamment intéressants pour éprouver notre démarche DDD et les différents styles d'architectures logicielle ciblés. Il y a même certains concepts de progressions temporelles qui semblent un terrain de jeu idéal pour faire de l'event sourcing.
• Le contexte et les concepts métier en tant que tels ne sont pas très compliqués à se représenter. Nous allons parler d'équipe, de matchs, de classement, de joueurs, de coachs etc. Donc des concepts assez simple à prendre en main au premier abord, ce qui permet au lecteur occasionnel de ne pas être totalement largué.
• Il y a déjà des utilisateurs ( environ 500 à la louche ) ce qui donne à l'ensemble une certaine réalité. En gros, il y a des vrais gens qui vont se servir de notre système. Et qui vont gueuler si ça ne marche pas.
• On a les experts du domaine sous la main, donc cela sera simple de mener des ateliers pour formaliser l'ubiquitous language et l'analyse fonctionnelle stratégique

Une première liste de fonction

En toute logique cette première liste de fonction doit être issue de la partie stratégique de notre démarche Domain Driven Design, mais je déflore un peu le sujet en amont, pour permettre à tout le monde de voir un peu mieux là ou nous allons mettre les pieds.
En première approximation, le système doit permettre de :
- gérer le cycle de vie d'un club, avec ses compétitions et les calendrier afférents
- créer des saisons, les poules, les règles de classement
- Permettre au joueurs demander à inscrire une de leur équipe sur une compétition, demande qui devra être validée par un commissaire de la compétition en question
- Saisir des rapports de matchs, avec une double validation des joueurs avant publication. Il devra également être possible de dé-publier un rapport pour le corriger et appliquer les nouveaux changements induits.
- Calculer les progressions des joueurs et des équipes

Mais aussi de :
- présenter son club au travers d'une page dédiée et administrable simplement
- présenter une compétition au travers d'une page dédié
- écrire des articles de fluff, ou de rapport narratif de match

Pas mal de choses en fait.
Pas mal de choses simples, ou moins simples.

Voila donc la problématique, que nous nous proposons de résoudre et automatiser, grâce au Domain Driven Design, tout au long des articles de ce site.

Nous allons d'ailleurs commencer directement avec la partie stratégique du Domain Driven Design, via un article qui présente le plan de bataille que nous allons suivre.

Un blog sur la tech, le python, le DDD, l'architecture logicielle... bref plein de trucs cools.

Avec beaucoup de python dedans.