Le Domain Driven Design (DDD) a la particularité d’être compliqué à expliquer. Ce sera donc exactement le but de cette conférence. On a tendance à penser que le DDD est complexe, mais c’est au final beaucoup de bon sens. C’est la quantité de chose couverte par le DDD qui le rend difficile à appréhender au début. Avec des retours d’expériences sur des pratiques concrètes du quotidien, que vous pourrez appliquer dès demain, nous verrons comment rendre votre projet plus centré sur le domaine. Nous verrons également quels principes sont respectés grâce à ces pratiques, et en quoi cela peut être bénéfique pour une équipe, donc pour une entreprise.

1. Daily DDD
Les pratiques du quotidien qui peuvent changer une équipe

2. http://www.ouarzy.com
@ouarzy
Emilien Pecoul

3. Domain Driven Design
520 pages (!)
@ouarzy

4. Que signifie concevoir un logiciel?
@ouarzy

5. @ouarzy
Abstraire
De A à Z
Que signifie concevoir un logiciel?

6. Domain Driven Design
@ouarzy

7. Domain Driven Design
@ouarzy

8. Domain Driven Design
@ouarzy

9. Domain Driven Design
@ouarzy

10. Le monde du DDD
Anemic Domain ModelUbiquitous Language
Bounded Context
CQS
Domain Services
Event Sourcing
CQRS
Event Storming
Entities
Value Objects
Aggregate
@ouarzy

11. Le DDD c’est compliqué
Par quel bout on le prend?
#DDDReboot!
@ouarzy

12. Stratégie VS Tactique
-Domain/SubDomain
-Bounded Context
-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’est compliqué
@ouarzy

14. Le DDD c’est compliqué
@ouarzy

15. Le DDD peut me 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. DDD et micro-services
@ouarzy

22. Prenons des exemples
au quotidien
@ouarzy

23. Bounded Context
Vente Support Envoi Recommandation
@ouarzy

24. Bounded Context
@ouarzy

25. Bounded Context
@ouarzy
Créer un modè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 pas peur de dupliquer la donnée pour créer une
abstraction clair par contexte.

27. Merci
@ouarzy

28. Comment on trouve les contextes?
@ouarzy
Interview d’ExpertEvent Storming
Analyser les dépendances
Impact Mapping

29. Ne pas jouer au 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
Expert métier
Problème
Expert métier
Développeuse
Testeur
@ouarzy
Résoudre les problèmes ensemble

31. Résoudre les problèmes ensemble
Rencontrer les utilisateurs!
@ouarzy

32. Résoudre les problèmes ensemble
Pair/Mob Programming Code Review
@ouarzy

33. Aligner le code et 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
- Bases de Données (ORM)
- Controller web
- Vues
-API Distantes
- Logique métier
- Ubiquitous Language
Aligner le code et le métier
@ouarzy

35. Aligner le code et le métier
Architecture hexagonale
@ouarzy

36. Aligner le code et le métier
Montrez votre code aux experts métier…
…Ils ne comprennent pas?
Vous êtes le problème.
@ouarzy

37. Documentation vivante
Aligner le code et le métier
@ouarzy

38. Changelog à partir des commits
Aligner le code et le métier
@ouarzy

39. Tester, car le mé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 pratiques pour un Feedback rapide
Un code simple à modifier
@ouarzy

41. Du code lisible
Un code 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’est surtout des bonnes habitudes au quotidien…
Bref 1/3
…Pour toute l’entreprise!
@ouarzy

43. Et le respect de l’expertise de chacun
Bref 2/3
@ouarzy

44. Dans un contexte bien défini
Bref 3/3
@ouarzy

45. References
https://leanpub.com/livingdocumentationLiving Documentation
Event Storming
@cyriux
https://leanpub.com/introducing_eventstorming
@ziobrando
Domain Driven Design:Tackling Complexity In The
Heart of Software@ericevans0
@ScottMillett
Patterns, Principles and Practices of DDD

46. References
Hexagonal Architecture
#DDDReboot
@TotherAlistair
@tpierrain et jgrodziski
Impact Mapping
@gojkoadzic
Domain Modeling Made Functional
@ScottWlaschin

47. http://www.ouarzy.com
Merci !
@ouarzy
Emilien Pecoul