DDD Strategic patterns : CR du book club software craftsmanship

La semaine dernière se tenait la 4ème session du bookclub software craftsmanship. Pour cette session, nous avions choisit de lire la partie 4 du livre Domain Driven Design d’Eric Evans.

Parmi les trois principes de base du strategic design (contexte, distillation et structures a grande échelle), nous avons principalement abordé les deux premiers.

Plusieurs personnes ont partagé leur expérience (douloureuse) d’avoir une approche CUSTOMER/SUPPLIER TEAMS ou CONFORMIST, avec des modules qui sont gérés par des équipes et une direction différente. En effet, dès que le le module en amont publie des modifications, le module en aval a de grandes chances de ne plus fonctionner. Ce phénomène est amplifié si le module en aval ne communique pas sur ses changements, et la situation devient carrément intenable quand le module en aval a adopté une approche conformiste avec plus de 2 ou 3 autre modules amont.

Nous avons ensuite imaginé comment mettre en place une ANTI CORRUPTION LAYER pour protéger le module aval ou un PUBLISHED LANGUAGE dans le cas de dépendance a de multiples modules amont.

D’une manière générale le choix du type d’intégration peut être déterminé par le “volume métier” partagé, l’organisation des équipes et la quantité / intensité des échanges entre les deux contextes.

Nous avons ensuite parlé de comment utiliser la distillation pour explorer un nouveau projet : identifier les contextes avec une CONTEXT MAP, un DOMAIN VISION STATEMENT ou un Event Storming.

Concernant le chapitre 15, nous avons clarifié la différence entre les BOUNDED CONTEXTS et les stratégies de distillation : les GENERIC SUBDOMAINS et COHESIVE MECHANISM ne sont des stratégies pour isoler et mettre en valeur le CORE DOMAIN mais forment pas forcément des BOUNDED CONTEXTS.

En fin de session, nous sommes revenus sur ce qu’est DDD, et par où commencer. En expliquant certaines implémentations comme l’Architecture Hexagonale et Event Sourcing, certains concepts sont devenus plus clairs.

Et pour savoir par où commencer, je partage l’avis et l’expérience d’Émilien : les tests sont un bon vecteur d’approche :

• ils permettent de faire pénétrer l’UBIQUITOUS LANGUAGE dans le code (voir BEHAVIOUR DRIVEN DEVELOPEMENT)
• ils mettent en lumière les problèmes de dépendance vers les éléments extérieurs au DOMAIN MODEL (persistence, matériel connecté, etc.) et forcent a créer des abstractions pour isoler le DOMAIN MODEL pour qu’il soit testable (ex interface & pattern repository).

Pour participer aux prochaines sessions du book club n’hésitez pas a rejoindre le meetup Software Craftsmanship Lyon pour connaitre les prochaines dates !