Le #MeetupDeconfinement sur le #DDD stratégique par @Lilobase , ça commence maintenant @benextcompany ! 
"Un seul VP / Chef doit venir râler quand un bout du programme pète."
Ce sont nos *domaines* qui apparaissent. On ne parle pas encore de micro-service, de bounded-context...
Cette modélisation se construit progressivement, et évolue. Ce n'est pas parfait tout de suite.
Des sous-domaines apparaissent.
On peut mettre à plat et hiérarchiser.
Et classifier :)
Lorsque ce travail est fait, on peut mettre en valeur les relations entre ces domaines. On remarquera peut-être beaucoup d'entrées / sorties sur un domaine : c'est peut-être un élément critique pour notre business.
Toutes ces réflexions adresses le problème. Avec ça, on peut ensuite commencer à rechercher des solutions.
Erreur récurrente / piège dans lequel on tombe souvent : on se concentre sur la solution, sur le comment. On est encore dans une posture technique. Ca nous arrive à tous :)
On peut adapter notre stratégie en fonction de la hiérarchie de nos domaines. Où est-ce qu'il faut davantage investir (les core domain), où est-ce que l'on peut utiliser des solutions existantes (generic subdomain), où est-ce que l'on peut externaliser (supporting subdomain).
Bounded Context : ce ne sont PAS des micro-services, ce ne sont PAS des unités de déploiements.
Les frontières.
La première frontière : la frontière sémantique. Des mêmes mots peuvent avoir une signification différente. Un des grandes source d'erreurs.
La première frontière : la frontière sémantique. Des mêmes mots peuvent avoir une signification différente. Un des grandes source d'erreurs.
On évite les "god object", ces éléments trop centraux. Une modification sur ces objets auraient trop d'impacts, partout.
Attention : dans un Bounded Context, on peut éviter la duplication (DRY). Mais pas entre les Bounded Context. Mauvaise habitude.
Important : on évite les multiples relations, les "spaghettis" entre les entités. Le refactoring deviendrait compliqué. Si on doit discuter entre les Bounded Context, on passe par des API ou par des systèmes de traduction. Idem pour les events.
Pour protéger l'intégrité, on passe par des Aggregats. Toutes les interactions passeront par la racine.
Tous les éléments partagent le même cycle de vie.
Anti-pattern : ne pas mettre trop d'éléments dans un aggregat, car ils partagent TOUS le MEME cycle de vie. Par exemple, être conscient que supprimer l'aggregat supprime TOUS les éléments.
Anti Corruption Layer (ACL) : l'intermédiaire qui évite de corrompre les domaines. Parfois, ça ne va dans aucun des domaines, mais on a besoin de communiquer.
Ubiquitous language : ce n'est pas juste un glossaire, c'est un langage commun. Chaque Bounded Context a son Ubiquitous language.
Le Pair Programming avec l'expert du domaine devient possible, et offre un super feedback en temps réel. C'est même recommandé : c'est signe que la démarche du DDD est réussie.
La spécification est un vrai travail de collaboration avec dev, PO, expert du domaine, utilisateurs. On embarque tout le monde.
Il faut bien avoir en tête que ce qui partira en prod, c'est ce que les devs ont compris.
Un bouquin conseillé :
Question posée : est-ce que le DDD est parfois overkill ?
> Oui peut-être si on prends uniquement les patterns tactique. Mais il faut penser aux stratégies. C'est d'abord une analyse pour s'adapter à notre métier, c'est l'inverse de l'overkill.
> Oui peut-être si on prends uniquement les patterns tactique. Mais il faut penser aux stratégies. C'est d'abord une analyse pour s'adapter à notre métier, c'est l'inverse de l'overkill.
Un gros ACL peut être le signe qu'un nouveau Bounded Context va apparaitre.
Adapter du DDD à l'existant ? On y va progressivement, par petits bouts, avec les nouvelles choses que l'on fait. Et on rogne petit à petit l'existant, on profite des modifications du métier pour faire évoluer.
Là où il faut convaincre : on change notre façon de travailler. Souvent, ne pas dire qu'on va faire du DDD. Mais en faire, petit à petit, et embarquer.
Quels sont les outils/ateliers/autres que tu conseils Arnaud pour faire émerger les différents domaines et les classifier ? Event storming en est un. (d'autres à venir si ping twitter :p)
Peut-être une réponse asynchrone de @Lilobase ?
Non le DDD n'est pas là pour "accélérer". Au contraire, on va ralentir (au début) pour réfléchir et voir comment courir un marathon, ne pas s'essouffler sur le long terme. On évite d'être bloqué sur les évolutions plus tard, d'avoir un énorme legacy.
Meetup et Q&A terminé. Très intéressant. De la stratégie, et pas seulement du technique. Excellent, merci @Lilobase !
Bientôt en replay par ici : vimeo.com/benextcompany
Slides : speakerdeck.com/lilobase/intro…
