MARGO

Actualité

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 !


Domain Driven Design (DDD)
Haute Performance IT
Microsoft
Actualité

Margo dévoile son nouveau positionnement et sa nouvelle identité de marque

Paris, le 12 février 2018 – Margo, société de conseil française créée en 2005 et historiquement spécialisée en IT en finance de marché, fait évoluer son business model afin d’accompagner de nouveaux secteurs d’activités dans leur transformation. A cette occasion, l’entreprise dévoile également sa nouvelle identité de marque originale dotée d’un logo personnalisable.

12/02/2018 Découvrir 
Témoignage

Témoignage de Pierre, Business Transformation Officer chez Margo

C'est la qualité des échanges que j’ai pu avoir avec les dirigeants, et leur volonté d’aller de l’avant avec des risques mesurés, qui m’ont donné envie de relever le défi de la transformation de leur business model.

Découvrir 
Témoignage

Christophe, DockerMan

Margo était capable de me proposer des missions intéressantes avec des entretiens toujours en toute transparence avec les clients. Je me suis senti tout de suite en relation de confiance.

Découvrir 
Témoignage

Rémi, Microsoft Addict et consultant R&D chez Margo

Margo m’est apparue comme étant la société la plus élitiste en termes de recrutement et de missions proposées en Finance des marchés.

Découvrir 
Actualité

Pourquoi l'intelligence artificielle fascine-t-elle autant ?

Rémi, Microsoft Addict et Consultant chez Margo, était présent au salon et nous livre son retour d’expérience sur la keynote du mercredi « L’intelligence Artificielle au service de l’humain »

23/10/2017 Découvrir 
Actualité

Connaissez-vous les dernières évolutions d'AngularJS 2 ?

AngularJS est devenu le framework Javascript le plus populaire pour le développement d’applications web. Sorti en 2012, le framework a connu jusqu’à aujourd’hui plusieurs évolutions lui permettant de gagner en maturité et en performance. Aujourd’hui, AngularJS 2 n’a plus grand-chose à voir avec sa première version, et Google a décidé de faire des breaking-changes afin de remanier et repenser le framework.

31/03/2017 Découvrir