DDD : Mise en pratique avec Symfony

Présentation pendant un sfpot de l'Afsy à Marseille !

Code de démo utilisé : https://github.com/tyx/ddd-sample-symfony

1. DDD : Mise en pratique avec Symfony Il faut gratter des dédés par Timothée Barray - @timbarray - github : tyx VeryLastRoom
2. Disclaimer Présentation basée sur mes lectures et propres tests. Ne prenez pas tout comme argent comptant ;) On va parler de vrai applications web avec de vrais règles métiers. Toutes les applications ne se prettent pas forcément au DDD. Mais si vous savez déjà que vous allez tendre vers quelque chose de plus complexe, commencez au plus tôt !
3. De quoi on va parler ? Constat de la situation actuelle de bcp d'application web Qu'est-ce que le DDD ? Commencer à profiter du DDD sur une application legacy Symfony Allez plus loin encore
4. Constat Des applications web de plus en plus conséquentes + Des concepts de plus en plus compliqués + Du legacy de plus en plus vieux = Changements / Nouveautés de plus en plus compliqués.
5. Symptômes Symfony classique Encore trop de logique métier dans les controllers. DIC utilisé en Service Locator encore trop souvent. Difficulté à réutiliser notre code. Encore trop de couplage fort
6. Pourquoi on en arrive là ? Conditionné par Symfony et sa structure. Vouloir utiliser la dernière nouveauté de Symfony. Ne pas réfléchir en terme d'application globale. Le concept de Bundle poussé trop loin. Réfléchir à son model en fonction de son stockage.
7. Une alternative ? DDD : Domain Driven Design
8. Kezako DDD SOLID et du bon sens avant tout De l'organisation Framework comme un détail Doctrine, Redis, ... des détails aussi Focus sur le code qui crée la valeur : Le Domain Se mettre des barrières
9. D'où ça vient ? Début ya ~ 10 ans. Dans le monde Java et C# principalement pour le développement d'application lourde. Pas un buzzword sorti ya 1 an.
10. En Bref Commencez par penser vos modèles avant même de penser à les stocker. Toutes actions de votre application doit impliquer un model. Vos modeles doivent être au centre de tout. Tout concept que vous utilisez dans votre code doit être modélisé. Résultat : documentation par le code plus limpide
11. Legacy Code : Par où on commence ?
12. Contexte du legacy
13. La POO à la rescousse Un concept = une classe De petites classes pour profiter de l'encapsulation Une classe = namespace + un nom + nom d'attributs + nom de méthodes = Autant d'aide pour expliciter ce qu'on fait
14. STOP aux tableaux de transport !
15. Value Object : Concept métier encapsulé dans une classe : Money, CreditCard, Address, ... Doit être immutable ! Exemple DTO (Data Transfer Object) : Communication entre 2 parties : Client <=> Serveur, Model <=> Vue, ... Command Permet d'expliciter l'action que vous souhaitez réaliser : RegisterUserCommand, AddToBasketCommand Injecté seulement des scalaires. Rendez les le plus simple à construire possible. Exemple
16. Command ?
17. Une meilleure organisation de code Couche Présentation Couche Application Couche Domain Couche Infrastructure
18. Couche présentation Aucune connaissance métier. Le client de votre application. Ne doit communiquer qu'avec la couche Application
19. Couche Présentation Lit la requête Donne l'ordre Interprête la réponse Ca vous rappelle rien ?
20. Couche présentation Controller Vues CLI Form Symfony ?
21. Exemple
22. Et rien de plus !
23. Couche Application Porte d'entrée Chef d'orchestre Chaque comportement souhaité doit être matérialisé ici.
24. Exemple
25. Couche Application Facilement réutilisable !
26. Couche Model Le coeur Model !== Data store ! N'exposez que le minimum ! Discutez en !
27. Entity Un Model avec une identité.
28. Domptez votre métier !
29. Exemple
30. Couche Model Méthodes publiques avec du sens Stop les get, get, get, get => Service => set set, set, set Vos services pilotés par vos model Moins d'exposition, moins de risque de spaghetti
31. Mais où est passé doctrine ?
32. Couche Infra Un détails d'implémentation Séparation ce qu'on **veut faire** de **la manière** dont on le fait. Devient facilement Mockable. Augmente le focus sur le Model !
33. Cas particulier de la validation Arrêtez de vouloir valider tout avec le Validator Symfony 2 étapes de validation. Une validation classique, de type, de longueur, etc... Et une étape de validation métier DANS VOTRE MODEL ! On ne doit pas pouvoir construire un model dans un état invalide !
34. Pattern Repository Intermédiaire entre notre domain et l'infrastructure en charge de l'accès à nos ressources. Implémentation Doctrine trop couplée à doctrine. Il faut s'en sortir.
35. Allez plus loin encore.
36. Bounded Context Limiter notre code à un context pour travailler avec des périmètres plus restreint et donc plus simple à maitriser.
37. Bounded Context Un même concept peut avoir 2 models dans 2 bounded context différents. Des barrières pour garder les choses simples de chaque côté.
38. Aggregate Un ensemble de model de votre domain qui forment un tout cohérent. Eux seuls ont un repository Accès à une Entity Child par son AggregateRoot Un seul Aggregate par Bounded Context Merci Doctrine et le cascade persist
39. Domain Event Les events sont un concept qui marche bien. Profitons-en ! EventDispatcher Dédié Communication entre vos Bounded Context. Injectez y surtout des scalaires Et pourquoi pas demain penser à faire de l'event Sourcing ? Mais ça c'est une autre histoire...
40. En résumé Isolez vos Bounded Context : Prenez le temps Séparez en couches, même imparfaite pour commencer. Procédez itérativement pour construire vos barrières entre vos BC Reprenez le contrôle de vos Models
41. De la lecture
42. Questions ?