Chronique d'un projet * Driven Design

Présentation lors du Forum PHP 2015

Transcript

1. CHRONIQUE D’UN PROJET
 * DRIVEN DESIGN
2. ME, MYSELF AND I • Alexandre BALMES • Twitter //@pockystar • Indépendant • Et cofondateur de Vanoix (with the great @ubermuda)
3. ABOUT ➤ *DD ➤ BDD (Behat) ➤ SpecBDD (PhpSpec) ➤ DDD ➤ TDD
4. UN EFFET DE MODE ?
5. *DD POUR LES GROS PROJETS ? Quelle est la métrique qui détermine un “gros projet” ? (a) Les ressources qui lui sont allouées ? (b) Le montant en bas de la facture ? (c) Sa durée de vie ? (d) La réponse D
6. *DD PLUS COUTEUX ? ➤ Le critère création tests/budget est identique ➤ PhpSpec à pour intérêt principal de générer du code ➤ Ne pas oublier que le *DD nous incite avant tout à faire de l’objet.
7. AU FINAL ? ➤ L’objectif du *DD est de faciliter : ➤ La conception (= le design) de l’application sur le long terme ➤ Donc sa compréhension ➤ Donc sa maintenance ➤ Donc le transfert de compétence
8. UN PROJET RAD (RAPID APPLICATION DEVELOPMENT)
9. UN PROJET DESIGN-DRIVEN
10. BDD ET SPECBDD Rassurez-vous, le DDD arrive
11. STEP 1: IMPACT MAPPING
12. STEP 1: IMPACT MAPPING Feature: Want to grow up to 10 000 customers As a customer When I connect my Facebook account to website Then I get a discount coupon
13. STEP 2: MODEL STORMING
14. STEP 3: DOMAIN MODELING @domain Feature: Want to grow up to 10 000 customers Scenario: Connect my social account Given I am a registered customer with a new account When I want to add a social account to my social panel Then I can decide if I want to send mails to my friends Scenario: Get a discount coupon Given I just receive a mail from my friend When I confirm my subscription Then I will receive a 10% discount coupon And my friend a 20€ discount coupon
15. STEP 3: DOMAIN MODELING
16. STEP 3: DOMAIN MODELING composer require rmiller/behat-spec --dev
18. DOMAIN DRIVEN
 DESIGN DDD FTW \o/
20. “ Non mais le DDD, c’est (trop) compliqué ! — toi
21. DDD: COURBE D’APPRENTISSAGE
22. DDD: VOCABULAIRE ➤ Ubiquitous Language ➤ Domain Model (Entity / ValueObject) ➤ Aggregates ➤ Bounded Context ➤ Persistence ignorance (Repository)
23. DDD: ARCHITECTURE ➤ Application ➤ Domain ➤ Infrastructure Application Domain Infrastructure
24. DDD: PROCESSUS REQUEST RESPONSE […] DATA TRANSFER OBJECT DOMAIN
 EVENT […] PSR-7 DDD
25. EXEMPLES ?
26. DDD: TROP DE FICHIERS ? 1. Application/Controller/WritePostFormController::indexAction() 2. Application/Form/Type/WritePostType 3. Application/DTO/WritePostDTO 4. Application/Controller/WritePostController::indexAction() 5. Application/Service/PostService::checkDuplicateContent() 6. Infrastructure/Service/PostService::writePost() 7. Infrastructure/Persistence/ORM/PostRepository::add() 8. Domain/Event/PostIsWritedEvent
27. DDD: TROP DE FICHIERS ? 1. Application/Command/WritePostCommand::process() 2. Application/DTO/WritePostDTO 3. Application/Service/PostService::checkDuplicateContent() 4. Infrastructure/Service/PostService::writePost() 5. Infrastructure/Persistence/ORM/PostRepository::add() 6. Domain/Event/PostIsWritedEvent
28. DDD: TROP DE FICHIERS ? 1. Application/Command/WritePostCommand::process() 2. Application/DTO/WritePostDTO::construct() 3. Application/Controller/WritePostController::indexAction() 4. Application/Service/PostService::checkDuplicateContent() 5. Infrastructure/Command/WritePostCommand::construct() 6. Infrastructure/Handler/WritePostHandler::handle() 7. Infrastructure/Service/PostService::writePost() 8. Infrastructure/Persistence/ORM/PostRepository::add() 9. Domain/Event/PostIsWritedEvent
29. DDD RAD VS
30. DDD: AVANTAGES ➤ Une vraie agilité ➤ Pérennité du code ➤ Plusieurs niveaux de documentations technique ➤ Un code métier compréhensible par tous ➤ MVP vs MLP
31. DDD: INCONVÉNIENTS ➤ Le premier projet fait mal ➤ Le critère temps à court terme (pas vraiment DRY — quoi que) ➤ L’infaisabilité technique sur certains projets (Magento, Prestashop, Wordpress…)
32. BILAN ?
34. THXBYE! https://joind.in/15490