#5 - DDD Stratégique : Identifier les domaines et sous-domaines métier

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