Domain Driven Design

Transcript

1. DOMAIN DRIVEN DESIGN AKA DDD Romain TOUZÉ

2. ORIGINES Eric Evans

3. None

4. POURQUOI ? Modèle anémique Applications centrées sur la base de

   données Structurations techniques Sous utilisation de la POO (primitive obsession)

5. CONTROLLER, BEAN, SERVICE, IMPL…

6. QUE FAIT MON OBJET ?

7. None
8. None

9. LA BASE

10. UBIQUITUOUS LANGUAGE dans les CR de workshop… dans les specs

    dans les tests dans le code

11. ALLER VOIR LES MÉTIERS Dé nir les contextes délimités (bounded

    contexts) qui vont constituer l'application Acquérir le vocabulaire Challenger le métier BDD

12. BOUNDED CONTEXTS ?

13. BOUNDED CONTEXTS ? Utilisation d'un progiciel… Équipes différentes…

14. PROPOSITION D'IMPLÉMENTATION

15. DÉCOUPLER L'INFRASTRUCTURE DU CODE MÉTIER

16. ARCHITECTURE HEXAGONALE

17. ANTICORRUPTION LAYER

18. OBJETS

19. ENTITÉS Représente les éléments du domaine ayant un cycle de

    vie et un identi ant dans le SI. Objets muables

20. VALEURS (VALUE OBJECTS) Représente une donnée associée aux entités Objet

    immuables Évite l'obsession des primitives (primitive obsession)

21. EXEMPLE : UN MONTANT Integer ? Float ? OK, mais

    si je dois gérer plusieurs devises ? OK, mais si je dois faire de l'arithmétique en gérant plusieurs devises ?

22. AGRÉGATS Arborescence d'entités et de valeurs Les opérations se font

    sur la racine uniquement

23. SERVICES

24. EN GÉNÉRAL Les actions qui ne peuvent pas être portées

    par les objets eux-mêmes

25. REPOSITORY Récupération et stockage dans la couche de persistance

26. FACTORY Traduction des informations envoyées au système

27. RAPPEL

28. AUJOURD'HUI

29. LIMITATIONS Scalabilité ? Contextualisation lecture / écriture ?

30. SCALABILITÉ

31. CQRS Command Query Responsibility Segregation

32. CQRS

33. CQRS

34. CQRS

35. EVENT SOURCING

36. RÉFÉRENCE DDD Community CQRS, event sourcing, task based UI Hexagonal

    architecture

37. C'EST TOUT POUR MOI !