DDD session BrownBagLunch (FR)

1,010 views

Published on

A brief presentation on Domain-Driven Design, followed by the Context Game to better understand Bounded Contexts

Published in: Technology

DDD session BrownBagLunch (FR)

  1. 1. Overview Domain-DrivenDesign+ Hands-On Workshop Cyrille Martraire @cyriux
  2. 2. Passionate developer PARIS Since 1999 @cyriux
  3. 3. Paris Software Craftsmanship Community http://www.meetup.com/paris-software-craftsmanship/
  4. 4. TDD BDD DDD Legacy
  5. 5. 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
  6. 6. h"p://www.virtual-­‐genius.com/blog/post/Domain-­‐Driven-­‐Design-­‐Immersion-­‐Course-­‐e28093-­‐Part-­‐5.aspx
  7. 7. Seniors  Developers h"p://www.thisisio.ie/blog/arDcle/149/hiring_senior_developer
  8. 8. I. Putting the model to work II. Building blocks (Tactical DDD) III. Refactoring toward deeper insight IV. Strategic DDD
  9. 9. I. Putting the model to work II. Building blocks (Tactical DDD) III. Refactoring toward deeper insight IV. Strategic DDD
  10. 10. DDD +BDD +TDD = VERY GOOD FRIENDS! h"p://www.alicia-­‐logic.com/capspages/caps_viewall.asp?Dtleid=16
  11. 11. SouventDénaturé Sans outillage spécifique CQRS: + populaire Très respecté
  12. 12. UNE  CURIOSITÉ  SINCÈRE  POUR  LE   MÉTIER Au  commencement  : h"p://jnchaintreuil.com/et-­‐si-­‐le-­‐futur-­‐appartenait-­‐aux-­‐curieux/
  13. 13. Investir dans la connaissance métier Mini-­‐training  30mn   bi-­‐hebdo h"p://www.femmeactuelle.fr/jardin/jardinage-­‐les-­‐conseils/arroser-­‐son-­‐jardin-­‐pendant-­‐les-­‐vacances-­‐00873
  14. 14. Domain Expert h"p://bakchich-­‐old.staDc.ddz.fr/IMG/jpg_expert-­‐2.jpg
  15. 15. 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
  16. 16. 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
  17. 17. Invariants «  Le  marché  des  instruments  dérivés  est  à   somme  nulle  » Σ  Cash  Flows  (toutes  les  contreparDes)  =  0
  18. 18. 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é.
  19. 19. Bounded Contexts → Context Game
  20. 20. 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
  21. 21. In practice (code) 25
  22. 22. Modeling 26
  23. 23. *NOT* UML/MDA! h"p://depinfo.u-­‐cergy.fr/projets/close2u/fr/tag/uml/
  24. 24. 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
  25. 25. Signal to Noise ratio http://www.flickr.com/photos/28471130@N07/2666802097
  26. 26. Signal to Noise Ratio • SNR ≥ 80 % • Signal: CashFlow, CashFlowSequence, CashFlowEngine, FinancialProduct, BankHolidays, ReferenceData • Noise: CashFlowBuilder, CompositeEngine, ProductFactory, BankHolidaysDecorator, SMTPImpl
  27. 27. Tactical Patterns (to help write code with more signal less noise) 31
  28. 28. null Code concentré en mé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
  29. 29. [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
  30. 30. 3 kinds of classes: Value Objects Entities Services 34
  31. 31. 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  !
  32. 32. Equality  by  value Value Object
  33. 33. «  DayShiX  by  -­‐2   WORKING  days  » No  ge^er/se^er Immutable Enum Behavior!
  34. 34. • 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
  35. 35. Défini  par  une   idenDté  arbitraire NoDon  de  conDnuité   dans  le  temps Entities
  36. 36. 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
  37. 37. Ni  une  valeur  ni  une  enDté Services h"p://www.andeka.co.cc/2011/07/postbox-­‐251.html
  38. 38. Persistence Ignorance • You  can  defer  decisions  about  persistence  (and   UI)  for  a  long  Dme • Your  domain  must  NOT  care!
  39. 39. 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
  40. 40. Repository h"p://www.andeka.co.cc/2011/07/postbox-­‐251.html Interface DAO
  41. 41. A  predicate  to  filter   something Specification boolean isSatisfied(...);
  42. 42. Hexagonal Architecture h"p://pragprog.com/magazines/2009-­‐12/going-­‐naked Depends  on   nothing
  43. 43. Now for some practice Context Game
  44. 44. Context Game DDD
  45. 45. Context Game [préchauffe] “What's your ideal <kitten>?” •Grand-mère: doux, affectueux •Agent d’entretien: propre, ne perd pas de poils
  46. 46. Context Game “What's your ideal <customer>?” •Sales: •Shipping: •Marketing: •Billing: •Support: •Billed customer assistance:
  47. 47. Context Game “What's your ideal <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
  48. 48. Different perspectives MY customer is not the same as YOUR customer
  49. 49. “Describe what you need to represent customer in your context” •data •queries •stats •behaviors Let’s analyze further
  50. 50. “At Amazon, what a 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
  51. 51. Conflicting aspects suggest several contexts “I don’t need all these data to do that, I just need these 3 fields”
  52. 52. 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
  53. 53. Merci ! h"p://cathy313.centerblog.net/539-­‐bisounours
  54. 54. Merci!

×