#1 - DonkeyBlog : DDD par l'exemple.

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.