DDD en vrai, c'est pas magique - BDX I/O 2019

by Joel Ung and Cyril Beslay
https://www.youtube.com/watch?v=8KsTGSZFPaY

Transcript

1. DDD en vrai, c'est pas magique Joel Ung - Cyril Beslay
2. Qui sommes nous ? Joel Ung @joel_ung Cyril Beslay @fotozik
4. Historique
5. Cadre de travail • Plusieurs équipes • Relation OnShore & OffShore (décalage horaire) Ubiquitous language Séparation physique des équipes Métiers / Développeurs
6. Collaborez, échangez, mangez, vivez avec vos experts métiers
7. Méthode de travail • Contexte contractuel pas d’agilité • Cycle en V • Effet tunnel
8. Travaillez avec n’importe quelle méthode qui a des cycles courts et des feedbacks réguliers ♻
9. Lorem ipsum congue tempus Lorem ipsum tempus Domaine métier ubiquitous language Concepts DDD Cher le DDD ?
10. Exemple : Ubiquitous language
11. DDD = € “DDD c’est pas tout le temps, ce n’est pas partout, c’est quand ça en vaut la peine parce que ça va vous coûter plus cher mais ça va rapporter beaucoup plus encore” Cyrille Martraire - DDD, en vrai pour le développeur - DevoxxFr 2016
12. Tous les acteurs doivent être conscients des avantages apportés par DDD mais aussi de son coût de mise en place
13. Framework DDD • Framework propriétaire • Cadre contractuel : règles strictes, contraintes fortes
14. Mieux former mais laisser la liberté aux développeurs d’implémenter à leur manière leur vision du métier
15. Pilotage par le budget • Contraintes très fortes ◦ temps ◦ ressources • Peu de temps pour comprendre le métier..
16. Se focaliser sur les points importants et prévoir du temps pour la compréhension métier et la conception ⏳
17. Connaître son métier • Bounded contexts • Modélisation du domaine • Carte des contextes • Processus métier
18. Mener des ateliers et utiliser des méthodes comme l’Event Storming
19. Un reflet des domaines • Règles métiers dans le mauvais domaine • Règles métiers dans la mauvaise couche (logicielle) • Règles métiers en doublon
20. La vision des domaines doit être pensée en amont mais peut/doit évoluer
21. Spaghetti war • Aucune recopie de données • Beaucoup de dépendances entre domaines • Performances ↘
22. Il faut savoir dupliquer la donnée avec la bonne fréquence de rafraîchissement pour supprimer des dépendances
23. DDD everywhere • Utilisation de DDD pour concevoir les batchs • DDD dans les domaines support
24. Les composants techniques et de calcul doivent être pensés différemment
25. L’équipe • Équipe novice concernant DDD • Concepts clés à comprendre • Conception difficile
26. La conception sera faite de préférence par des ingénieurs expérimentés avec une appétence pour le métier
27. Ce qu’il faut retenir - Take-away • “Le cœur d’un logiciel est sa capacité à résoudre les problèmes liés au domaine pour son utilisateur.“ - Eric Evans • Soyez curieux et entraînez vos développeurs • DDD ne s’applique pas partout • Pour démarrer DDD, expérimentez sur une petite partie de votre SI et trouvez votre façon de l’appliquer
28. Open Feedback