Consultant
31.08.2017

Rémi au meet-up du Domain-Driven Design

La notion de DDD renvoie aux bases d’une bonne architecture de code.

C’est à ces trois lettres qu’était dédié le meet-up du 9 juin dernier dans les locaux de Microsoft.

 

Le Domain Driven Design : ça n’est pas un framework, pas une méthodologie mais une approche de conception de développement de logiciels pilotée par le domaine. C’est ce que les trois intervenants se sont appliqués à nous démontrer dans cette après-midi de live coding.

L’un porte le costume du dirigeant de start-up, les deux autres portent le tee shirt de développeur tout-terrain officiant en pair programming, pour répondre au business de cette start-up.

Les « techos » s’entretiennent avec l’expert du domaine de l’entreprise (ici une plateforme de réservation de billet de train), trouvent l’idée simple et les objectifs (corriger des bugs et ajouter une nouvelle fonctionnalité) tout à fait tenables.

La suite vous est certainement familière : ils clonent le repo, font face à l’existant -le legacy- puis révisent vite leur jugement…

 

- Eeeuhh vous êtes sûr que le code correspond bien au business dont on vient de parler?

- J’en sais rien, je ne suis pas développeur, je ne comprends rien au code.

Je sais que cette application me coûte aussi cher en maintenance que le prix de son développement initial. Je ne sais pas si elle est bugguée et le chiffrage de l’ancienne équipe pour la faire évoluer est exorbitant.

- On parle bien de train ici ? Il n’y a aucune classe qui porte le nom de train, ou même de réservation.

Il y a bien une classe Voiture mais c’est une classe adolescente.

 

Qu’est-ce qu’une classe adolescente ? C’est une classe qui n’a pas encore pris ses responsabilités, qui ne contient donc aucune fonction et qui est un simple conteneur.

 

S’en suit un florilège de mauvais design, de mauvais nommage, d’anti-pattern, de code mort, de projets de test vides… Cela vous semble toujours aussi familier ?

 

Les développeurs informent le client de l’état impraticable du projet et de la nécessité de le re-factorer. En adoptant une nouvelle approche où le métier est au cœur du design. Où chaque classe est responsable d’un seul comportement et porte la même appellation que celle utilisée par les experts du domaine.

Première étape : les tests unitaires pour s’assurer de ne pas perdre … Installer NCrunch dans Visual Studio permettra de s’assurer en temps réel qu’aucune portion de code ne viendra « casser » une fonctionnalité et aussi de détecter quelques bugs.

Tout ne se déroule pas sans encombre : le code n’est pas totalement testable : il faut mocker certains composants, créer des interfaces et mettre en place de l’injection de dépendances. Et on comprend mieux que l’expert du domaine ne puisse pas d’un coup d’œil voir le comportement de son application s’il doit démêler le code technique du code du domaine.

 

 

using (SqlConnection connection = new SqlConnection(connectionString))

{

    connection.Open();

if(voiture.IsFull())

{

}

}

 

Une architecture hexagonale, telle que décrite par Alistair Cockburn, a été mise en place. Une architecture hexagonale va à l’opposé de l’architecture en couches qui donne le vertige lorsqu’on visualise la pile d’appel au moment du debug et qui était largement répandue au début des années 2000.

Dans l’approche hexagonale, le code du domaine est au centre et le code de l’infrastructure autour.

Les interactions sont clairement identifiées par des interfaces et passent par des adaptateurs. 

 

Ainsi, quand un événement venant du monde extérieur intervient, il passe par son adaptateur spécifique et le transforme en une procédure compréhensible par le code du domaine qui lui est ignorant de la nature technique du signal. Quand le domaine a quelque chose à envoyer, il le fait via un adaptateur spécifique qui se charge de le transformer selon sa propre technologie.

L’intérêt est de pouvoir facilement exécuter le programme via une interface graphique, un autre programme, des tests automatisés, des scripts et de le développer de façon isolée d’éventuels périphériques ou composants externes.  Et surtout, cela aurait pu aider notre dirigeant !