Téléchargé 17 fois
Téléchargé parEmilien Pecoul
Daily ddd
Le document aborde le concept de Domain Driven Design (DDD) et son application dans le développement logiciel, en discutant des pratiques essentielles et des défis rencontrés. Il met en avant l'importance de créer des modèles abstraits dans des contextes bien délimités et souligne la nécessité d'une collaboration étroite entre les développeurs et les experts métier. Le texte propose également des stratégies pour aligner le code avec le sens métier et améliorer la communication au sein des équipes.
Daily ddd
- 1. Daily DDD Les pratiquesdu quotidien qui peuvent changer une équipe
- 2.
- 3. Domain Driven Design 520pages (!) @ouarzy
- 4. Que signifie concevoirun logiciel? @ouarzy
- 5. @ouarzy Abstraire De A àZ Que signifie concevoir un logiciel?
- 6.
- 7.
- 8.
- 9.
- 10. Le monde duDDD Anemic Domain ModelUbiquitous Language Bounded Context CQS Domain Services Event Sourcing CQRS Event Storming Entities Value Objects Aggregate @ouarzy
- 11. Le DDD c’estcompliqué Par quel bout on le prend? #DDDReboot! @ouarzy
- 12. Stratégie VS Tactique -Domain/SubDomain -BoundedContext -Context Maps -Composite -Shared Kernel -Conformist -Anti Corruption -… -Aggregate -Entities -Value Objects -Repositories -Factories -Domain Services -Application Services -… Où aller ? Comment y aller ? @ouarzy
- 13. Le DDD c’estcompliqué @ouarzy
- 14. Le DDD c’estcompliqué @ouarzy
- 15. Le DDD peutme servir ? @ouarzy
- 16. Anti DDD expressions «C’est juste une base de données » @ouarzy
- 17. Anti DDD expressions «Ce n’est pas mon problème si les specs sont fausses» « J’ai codé ce qui était demandé » @ouarzy
- 18. Anti DDD expressions «Ils ne savent pas ce qu’ils veulent ! » @ouarzy
- 19. Anti DDD expressions «On ne peut pas avancer tant que l’équipe X n’a pas terminée » « Il faut une équipe Backend et une équipe Frontend !» @ouarzy
- 20. DDD et micro-services «Mais on fait déjà des micro-services ! » @ouarzy
- 21.
- 22. Prenons des exemples auquotidien @ouarzy
- 23. Bounded Context Vente SupportEnvoi Recommandation @ouarzy
- 24.
- 25. Bounded Context @ouarzy Créer unmodèle c’est abstraire la réalité. Cette abstraction ne peut être valable que dans un contexte bien borné!
- 26. Bounded Context @ouarzy N’ayez paspeur de dupliquer la donnée pour créer une abstraction clair par contexte.
- 27.
- 28. Comment on trouveles contextes? @ouarzy Interview d’ExpertEvent Storming Analyser les dépendances Impact Mapping
- 29. Ne pas jouerau téléphone arabe ! « C’est ce que comprend (ou pas) le développeur qui ira en production, pas votre compréhension du métier... » @ouarzy Comment on trouve les contextes?
- 30. Chef de projet Expertmétier Problème Expert métier Développeuse Testeur @ouarzy Résoudre les problèmes ensemble
- 31. Résoudre les problèmesensemble Rencontrer les utilisateurs! @ouarzy
- 32. Résoudre les problèmesensemble Pair/Mob Programming Code Review @ouarzy
- 33. Aligner le codeet le métier Ubiquitous Language - 2 mots identiques doivent avoir le même sens métier - 2 mots différents ne doivent pas désigner un même concept @ouarzy
- 34. Domain Infrastructure - Basesde Données (ORM) - Controller web - Vues -API Distantes - Logique métier - Ubiquitous Language Aligner le code et le métier @ouarzy
- 35. Aligner le codeet le métier Architecture hexagonale @ouarzy
- 36. Aligner le codeet le métier Montrez votre code aux experts métier… …Ils ne comprennent pas? Vous êtes le problème. @ouarzy
- 37. Documentation vivante Aligner lecode et le métier @ouarzy
- 38. Changelog à partirdes commits Aligner le code et le métier @ouarzy
- 39. Tester, car lemétier va évoluer... Automatiquement, car vous n’aurez jamais le temps... Un code simple à modifier No time for testing death spiral Pressure TestingErrors + - + +- - @ouarzy
- 40. Des bonnes pratiquespour un Feedback rapide Un code simple à modifier @ouarzy
- 41. Du code lisible Uncode simple à modifier Trop de personnes supposent qu’un problème majeur de l’industrie logiciel est d’écrire du code, alors qu’il se trouve dans la lecture du code await Task.WhenAll(t1, t2, t3, t4); @ouarzy
- 42. Le DDD c’estsurtout des bonnes habitudes au quotidien… Bref 1/3 …Pour toute l’entreprise! @ouarzy
- 43. Et le respectde l’expertise de chacun Bref 2/3 @ouarzy
- 44. Dans un contextebien défini Bref 3/3 @ouarzy
- 45. References https://leanpub.com/livingdocumentationLiving Documentation Event Storming @cyriux https://leanpub.com/introducing_eventstorming @ziobrando DomainDriven Design:Tackling Complexity In The Heart of Software@ericevans0 @ScottMillett Patterns, Principles and Practices of DDD
- 46. References Hexagonal Architecture #DDDReboot @TotherAlistair @tpierrain etjgrodziski Impact Mapping @gojkoadzic Domain Modeling Made Functional @ScottWlaschin
- 47.