Télécharger en tant que PDF, PPTX
![[Object Calisthenics]
1. Wrap all primitives and strings
2. Use only one dot per line
3. Don’t abbreviate
4. Keep all classes small
5. Don’t use any classes with more than
two instance variables
6. Use first-class collections
7. Don’t use any getters/setters/
properties](https://image.slidesharecdn.com/dddsessionbbl-130925163755-phpapp01/85/DDD-session-BrownBagLunch-FR-33-320.jpg)
![Context Game
[préchauffe]
“What's your ideal <kitten>?”
•Grand-mère: doux,
affectueux
•Agent d’entretien: propre,
ne perd pas de poils](https://image.slidesharecdn.com/dddsessionbbl-130925163755-phpapp01/85/DDD-session-BrownBagLunch-FR-49-320.jpg)
Téléchargé parCyrille Martraire
DDD session BrownBagLunch (FR)
Ce document présente un atelier pratique sur le design piloté par le domaine (DDD), soulignant l'importance de prioriser le domaine et d'utiliser un langage commun à la fois dans le code et les tests. Il aborde des concepts clés tels que les contextes délimités, les objets de valeur, et l'architecture hexagonale, tout en insistant sur l'importance d'une modélisation claire et d'un code lisible. Le document intègre également des exemples concrets et des pratiques recommandées pour appliquer DDD efficacement dans des projets de développement.
![[Agile Testing Day] Behavior Driven Development (BDD)](https://cdn.slidesharecdn.com/ss_thumbnails/bddagiletestingday-george-160126180604-thumbnail.jpg?width=640&height=640&fit=bounds)
DDD session BrownBagLunch (FR)
- 1. Overview Domain-DrivenDesign+ Hands-On Workshop CyrilleMartraire @cyriux
- 2.
- 3.
- 4.
- 6. Executive Summary Domain-Driven Design: • Priorité au domaine, devant la technique • Parler le langage du métier, pour tout le monde, dans le code et dans les tests • Le code est le modèle (et vice-versa) • Mon arme secrète sur mes projets depuis 2005
- 9.
- 10.
- 11. I. Putting the modelto work II. Building blocks (Tactical DDD) III. Refactoring toward deeper insight IV. Strategic DDD
- 12. I. Putting the modelto work II. Building blocks (Tactical DDD) III. Refactoring toward deeper insight IV. Strategic DDD
- 13. DDD +BDD +TDD =VERY GOOD FRIENDS! h"p://www.alicia-‐logic.com/capspages/caps_viewall.asp?Dtleid=16
- 14. SouventDénaturé Sans outillage spécifique CQRS: +populaire Très respecté
- 15. UNE CURIOSITÉ SINCÈRE POUR LE MÉTIER Au commencement : h"p://jnchaintreuil.com/et-‐si-‐le-‐futur-‐appartenait-‐aux-‐curieux/
- 16. Investir dans la connaissancemétier Mini-‐training 30mn bi-‐hebdo h"p://www.femmeactuelle.fr/jardin/jardinage-‐les-‐conseils/arroser-‐son-‐jardin-‐pendant-‐les-‐vacances-‐00873
- 17.
- 18. Le langage compte! •La modélisaDon commence avec le langage • A"enDons aux « synonymes » et aux mots centraux du méDer • Poser des bonnes (meilleures) quesDons h"p://journalism.about.com/od/reporDng/tp/Finding-‐And-‐Developing-‐Ideas-‐For-‐News-‐Stories-‐And-‐ArDcles.htm
- 19. Ubiquitous Language • Nommer •Facileà chercher •Prononçables •Sans abréviation • Définir •Définition partagée •Comprendre, pas juste un vocabulaire h"p://scalin.fr/rubrique-‐technique/glossaire
- 20. Invariants « Le marché des instruments dérivés est à somme nulle » Σ Cash Flows (toutes les contreparDes) = 0
- 21. Bounded Contexts Il n’est pas possible de convenir du sens précis des mots uDlisés par un grand nombre de personnes. Il faut accepter ce fait, et donc définir dans quel contexte un langage est clairement défini sans ambiguité.
- 22.
- 23. En gros • DDD : façon d’aborder les problèmes + soluDons •Focus sur le méDer •Focus sur un langage méDer omniprésent •Focus sur le core domain
- 25.
- 26.
- 27.
- 28. No Translation: Code ==Model • Ubiquitous Langage dans le code • Noms de classes & interfaces • Noms de méthodes • Code lisible en prose autant que possible •≥ 80% noms de classes & méthodes lisibles par le méDer
- 29. Signal to Noiseratio http://www.flickr.com/photos/28471130@N07/2666802097
- 30. Signal to NoiseRatio • SNR ≥ 80 % • Signal: CashFlow, CashFlowSequence, CashFlowEngine, FinancialProduct, BankHolidays, ReferenceData • Noise: CashFlowBuilder, CompositeEngine, ProductFactory, BankHolidaysDecorator, SMTPImpl
- 31. Tactical Patterns (to helpwrite code with more signal less noise) 31
- 32. null Code concentré enmétier • 100% méDer (ou presque) • No framework polluDon • Spring, Hibernate, logger • No javax.* • No SQL • Only h"p://code.google.com/p/guava-‐libraries/ Dans le modèle de domaine
- 33. [Object Calisthenics] 1. Wrapall primitives and strings 2. Use only one dot per line 3. Don’t abbreviate 4. Keep all classes small 5. Don’t use any classes with more than two instance variables 6. Use first-class collections 7. Don’t use any getters/setters/ properties
- 34. 3 kinds ofclasses: Value Objects Entities Services 34
- 35. Value Object • No parDcular idenDty, equality by value • Immutable • Constructor / StaDc Creator / Factory method • FP-‐Style • Side-‐effect-‐free Mon choix par défaut, sauf si vraiment pas possible !
- 36. Equality by value ValueObject
- 37. « DayShiX by -‐2 WORKING days » No ge^er/se^er Immutable Enum Behavior!
- 38. • Fowler pa"erns: QuanDty, Range, Money... • Functional programming style • Immutable, clone to mutate • Capture values (snapshot) • History object of every version • Builder to help creation • Common example: • String & StringBuilder Value Object
- 39. Défini par une idenDté arbitraire NoDon de conDnuité dans le temps Entities
- 40. Une collecDon d’objets liés qui partagent une cohérence ensembles, avec une enDté racine pour l’idenDté : Aggregate Root Aggregates h"p://www.boitearece"es.com/fruits_legumes/raisin-‐text.htm
- 41. Ni une valeur ni une enDté Services h"p://www.andeka.co.cc/2011/07/postbox-‐251.html
- 42. Persistence Ignorance • You can defer decisions about persistence (and UI) for a long Dme • Your domain must NOT care!
- 43. Un service, la facade coté méDer d’un stockage Sans jamais parler de base de données. Repository h"p://www.andeka.co.cc/2011/07/postbox-‐251.html
- 44.
- 45. A predicate to filter something Specification boolean isSatisfied(...);
- 46.
- 47.
- 48.
- 49. Context Game [préchauffe] “What's yourideal <kitten>?” •Grand-mère: doux, affectueux •Agent d’entretien: propre, ne perd pas de poils
- 50. Context Game “What's yourideal <customer>?” •Sales: •Shipping: •Marketing: •Billing: •Support: •Billed customer assistance:
- 51. Context Game “What's yourideal <customer>?” •Sales: Impulse buyer, lots of money, lots of needs •Shipping: Lives nearby, always at home •Marketing: Very gullible •Billing: Very solvable, pays in advance cash •Support: Very clever, never needs any help •Billed customer assistance: Very stupid, can’t manage to do anything without help
- 52. Different perspectives MY customeris not the same as YOUR customer
- 53. “Describe what youneed to represent customer in your context” •data •queries •stats •behaviors Let’s analyze further
- 54. “At Amazon, whata book is for you?” •Catalog: Picture, title, authors, rating, format (ebook or paper), category •Recommandation: List of books often bought together with it •Shipping: Dimensions, weight, international restrictions due to content •Shopping cart: Price, discount eligible •Customer review: List of (rating, review, review rating) •Book Search: title, isbn, authors •Search Inside!: full-text content, copyright- dealing policy
- 55. Conflicting aspects suggest severalcontexts “I don’t need all these data to do that, I just need these 3 fields”
- 56. Several contexts = opportunities Simplify:Isolated bounded contexts Vs Union of all in one universal do-it-all object Partitioning: Full-Stack Autonomous Components (screen mashup) Vs. Bounded Contexts in domain layer only; CQRS Partitioning: teams, work in parallel; scalability; no cross context Tx, EC
- 61.
- 62.