Le Domain Driven Design sous l’angle stratégique, une introduction

Le Domain Driven Design sous l’angle stratégique, une introduction

La semaine dernière j’ai eu la chance d’être invité à donner un talk sur le sujet du domain driven design.

Ce talk a été motivé par une observation que j’ai pu faire. Beaucoup d’équipes de développement passent, malheureusement, à côté du principal bénéfice qu’apporte une conception logicielle pilotée par le métier.

En effet, de nombreuses conférences ou articles se concentrent sur les aspects tactiques du DDD. C’est-à-dire, comment utiliser certains patterns techniques pour construire une application qui est alignée avec le problème métier ?

Le fait de se focaliser sur les aspects tactiques, et donc techniques du DDD masque la partie la plus importante du DDD : les aspects stratégiques.

Effectivement, au-delà de proposer une boite à outil technique, le DDD est, avant tout, une manière de réfléchir à la problématique métier que nous cherchons à résoudre.

Et en partant de cette réflexion, nous pouvons choisir plus efficacement quels outils et quels patterns nous allons pouvoir utiliser pour construire le logiciel.

C’est pourquoi, dans ce talk je présente les aspects stratégiques du Domain Driven Design, et comment ceux-ci peuvent aider à avoir une conception alignée avec le métier que nous cherchons à implémenter.

Erratum: dans la conférence j’ai interverti les termes de « generic subdomain » et « supporting subdomain »

Vidéo de la conférence "La stratégie derrière le domain driven design"

Vous trouverez les slides de la conférence sur mon speakerdeck.

Mise à jour

J'ai eu l'occasion de présenter la suite de cette conférence lors d'un meetup. Où j'y explique les erreurs fréquentes que l'on retrouve dans les modèles de communication et comment les éviter.


Pour être tenu au courant des prochains articles ou conférences, abonnez vous à la newsletter. Et si vous avez apprécié la conférence, n'hésitez pas à la partager sur twitter, Linkedin, ou sur Slack.