Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Coder sans peur du changement avec la meme pas mal hexagonal architecture

2 215 vues

Publié le

Découvrez en pratique l'architecture hexagonale, indispensable pour vos applications complexes !

Ce style d'architecture permet d'adapter votre code à tout changement de technologie sans souffrir. Si vous aimez changer de frameworks ou de librairies, tester correctement ou appliquer le Domain-Driven Design, alors vous avez besoin d'architecture hexagonale !

Avec des exemples en code Java, et au travers d’un kata d’architecture auquel vous pourrez participer, nous vous montrerons les pièges à éviter et comment mettre en œuvre ce pattern sans trop galérer, et ce dès votre retour au bureau !

Publié dans : Logiciels
  • Soyez le premier à commenter

Coder sans peur du changement avec la meme pas mal hexagonal architecture

  1. 1. @cyriux @tpierrain#MemePasMal Coder sans peur du changement, avec la "même pas mal !" architecture hexagonale Cyrille MARTRAIRE (@cyriux) Arolla ! Thomas PIERRAIN (@tpierrain) Société Générale
  2. 2. @cyriux @tpierrain#MemePasMal CODER  SANS  PEUR  DU  CHANGEMENT,  AVEC  LA  "MÊME  PAS   MAL  !"  ARCHITECTURE  HEXAGONALE Cyrille MARTRAIRE (@cyriux) Arolla ! Thomas PIERRAIN (@tpierrain) Société Générale
  3. 3. Architecte Société Générale Thomas Pierrain
  4. 4. 6
  5. 5. 7
  6. 6. Passionate developer PARIS Since 1999 ! @cyriux Cyrille Martraire
  7. 7. Paris Software Craftsmanship Community http://www.meetup.com/paris-software-craftsmanship/
  8. 8. TDD BDD DDD Legacy
  9. 9. Architecte Technique Central
  10. 10. Architecte Technique Central
  11. 11. Your own Sweets Box Online! Use-cases 1. Choose your box and the sweets to put inside 2. Get a price 3. Order, & consult past orders
  12. 12. Let’s start
  13. 13. As usual:
 Chose the DB & 
 Design the DB schema!
  14. 14. STOP !
  15. 15. Alistair Cockburn
  16. 16. Uncle Bob Martin
  17. 17. Hexagonal
  18. 18. 100% Domain Inside
  19. 19. Thin layer of Use-cases
  20. 20. Ports/Adapters all around
  21. 21. Adapter
  22. 22. Dependencies always 
 towards the inside! X Allowed way for dependencies
  23. 23. Dependencies always 
 towards the inside! Vers  l’intérieur,  qu’il   dit  le  monsieur  !
  24. 24. Ports/Adapters? “REST”Port “REST” Adapter “EMS“ Adapter “Tibco EMS” Port
  25. 25. Hexagonal?
  26. 26. Users Vs. Providers THEY 
 NEED ME I NEED THEM API (Application Provider Interface) SPI (Service Provider Interface)
  27. 27. Tests Vs. Production Deliver value to PROD Verify behavior in TEST Test Robots Fakes, Mocks Clients Stores etc.
  28. 28. Scenario-Driven… Given a sweets box of size XL And a selection of 500g of M&Ms And assuming the following prices | item | price | currency | | XL Box | 2.50 | EUR | | M&M (100g)| 5.00 | EUR | ! When I ask for a price Then the price is 27.50 EUR
  29. 29. Modeling the domain… Sweets CustomSweetsBox SweetsBoxPricer AllOrders Catalog Order ShippingCostEstimat or Caramels Nougat Fudge
  30. 30. Modeling the domain… Sweets CustomSweetsBox SweetsBoxPricer AllOrders Catalog Order ShippingCostEstimat or Caramels Nougat Fudge Beware of Modelism!
  31. 31. I need to call external services, but I don’t want to know about them
  32. 32. DIP principle X
  33. 33. DIP principle Interface Adapter
  34. 34. interface
  35. 35. interface REPOSITORY
  36. 36. interface Start with mocks MOCK
  37. 37. Add an html web app… “REST” Adapter
  38. 38. We can demo!
  39. 39. Quick Win 1
 Focus on what really matters
  40. 40. Implement the repository
  41. 41. Implement the repository On the cloudz!
  42. 42. Implement actual persistence interface Amazon Adaptor
  43. 43. Même pas mal !
 (“that didn't hurt one bit“)
  44. 44. Quick Win 2
 Choose the technology last (when we know best)
  45. 45. 47 MAX IGNORANCE
  46. 46. 48 Who’s  that  architect   who  can’t  decide  the   technologies  early?
  47. 47. Ebay as additional retailer?
  48. 48. Ebay as additional retailer! “REST” Adapter Ebay Adapter
  49. 49. Même pas …
  50. 50. New shipping provider?
  51. 51. interface FEDEX Adaptor New shipping provider?!
  52. 52. Again:
 Même pas mal !!!
  53. 53. Quick Win 3
 Embrace the changes
  54. 54. X Allowed way for dependencies Hexagonal architecture
  55. 55. Quick Win 4
 Low coupling
 High cohesion
  56. 56. Before 
 (legacy architecture)
  57. 57. After
 (Hexagonal Architecture)
  58. 58. Quick Win 5
 Our business code is not victim of IT fads anymore!
  59. 59. 61
  60. 60. Hexagonal Architecture Use & Abuse!
  61. 61. Need other areas of behaviors? • Business intelligence? • Supply Chain management • CRM? • …
  62. 62. Même pas ! 
 ;-)
  63. 63. Hexagonal all the things New Bounded Contexts? New Micro-services?
  64. 64. Main benefits ! 1.Focus on what really matters
 (business value first!) ➔ have you ever tried DDD? ! 2.Choose the technology last 
 (when we know best our concrete needs) ! 3.Embrace the changes 
 (“Même pas mal !” / “that didn't hurt one bit“)
  65. 65. Thanks! Cyrille MARTRAIRE @cyriux Thomas PIERRAIN @tpierrain
  66. 66. @cyriux @tpierrain#MemePasMal CODER  SANS  PEUR  DU  CHANGEMENT,  AVEC  LA  "MÊME  PAS   MAL  !"  ARCHITECTURE  HEXAGONALE Cyrille MARTRAIRE (@cyriux) Arolla ! Thomas PIERRAIN (@tpierrain) Société Générale
  67. 67. 70
  68. 68. FUZZY
  69. 69. FUZZY
  70. 70. FUZZY
  71. 71. Pattern
  72. 72. Port Vs Adapter?
  73. 73. Port = Existing Techno Adapter = Your code
  74. 74. You disagree?
  75. 75. Not that important.
  76. 76. Symmetries? 80
  77. 77. Not that important.
  78. 78. Inside vs. Outside
  79. 79. Who’s talking about hexagonal?
  80. 80. Alistair Cockburn 84
  81. 81. ”Uncle Bob” Martin 85
  82. 82. Steeve Freeman & Nat Pryce (GOOS) 86
  83. 83. Vaughn Vernon (IDDD) 87
  84. 84. Jeffrey Palermo (Onion Architecture) 88
  85. 85. h;p://pragprog.com/magazines/2009-­‐12/going-­‐naked Depends  on   nothing Pragmatic Programmers
  86. 86. Many notations!
  87. 87. Still, not well-known
  88. 88. +--------------+! | presentation |! |--------------|! | domain |! |--------------|! | persistence |! +--------------+ Layers?
  89. 89. +-----+-------------+----------+! | gui | file system | database |! |-----+-------------+----------+! | domain |! |------------------------------+ Infra the other way round! Layering http://matteo.vaccari.name/blog/archives/154
  90. 90. Inside vs. Outside
  91. 91. Un Dedans et Un Dehors
  92. 92. Un Dedans et Un Dehors #des reperes pour nos enfants
  93. 93. For real
  94. 94. 98
  95. 95. 99 Ted Neward
  96. 96. We’re launching a startup, man.
  97. 97. Sentiment Analysis ! Automatically extract the sentiment of English sentences submitted on the web, using a given lexicon. Keep track of the submitted sentences.
  98. 98. Your Turn ! 5mn Small groups Any technology / approach Propose an architecture on paper ! Then we’ll debrief a selection of them
  99. 99. Sentiment Analysis ! Automatically extract the sentiment of English sentences submitted on the web, using a given lexicon. Keep track of the submitted sentences.
  100. 100. 105
  101. 101. How to enforce?
  102. 102. 108 http://books.sonatype.com/mvnref-book/reference/flex-dev-sect-creating-with-archetype.html Maven multi- module
  103. 103. 109 http://clarkware.com/software/JDepend.html JDepend
  104. 104. 110https://leanpub.com/livingdocumentation/
  105. 105. 111 Living Diagrams
  106. 106. 4  novel  coupling  metrics   1. Undesirable  Dependency  Count   2. Undesirable  Distinct  Dependency  Count   3. Undesirable  Dependency  Max  Repetition   4. Undesirable  Distinct  Assembly  Count   !   Bad Good ● Provoke conversations
  107. 107. Conformist vs. Hexagonal
  108. 108. Conformist (accidental)
  109. 109. Hexagonal Architecture
  110. 110. Hexadecimal Architecture: Need at least 16 layers in the code
  111. 111. Architecture = ?
  112. 112. Architecture ! ”The key technology choices” BOF…
  113. 113. Architecture ! ”What everybody should know”
  114. 114. Architecture ! ”What’s hard to change”
  115. 115. Architecture ! ”What’s irreversible”
  116. 116. Reversible decisions FTW! Defer technology decisions Change your mind easily
  117. 117. 50% TECH 50% COMM
  118. 118. 50% TECH 50% COMM (10% MATHS)
  119. 119. Communication FTW!
  120. 120. AGREE ON MAXIMS
  121. 121. ”Le principe du nombril : on regarde vers l’intérieur”
  122. 122. Repository
  123. 123. Persistence Ignorance ! ! •You  can  defer  decisions  about   persistence  (and  UI)  for  a  long  ^me   •Your  domain  must  NOT  care!
  124. 124. Un  service,  la  facade  coté   mé^er  d’un  stockage   ! Sans  jamais  parler  de  base   de  données. Repository h;p://www.andeka.co.cc/2011/07/postbox-­‐251.html
  125. 125. Repository h;p://www.andeka.co.cc/2011/07/postbox-­‐251.html Interface DAO
  126. 126. Repository
  127. 127. In Legacy
  128. 128. Bubble Context • Create a little bubble of innovation ! • Brand new model ! • As clean as we like • Highly tested • High hygiene standards
  129. 129. Bubble Context • ACL to protect from the legacy code ! • Translates legacy objects & services into new, cleaner ones
  130. 130. Anti-corruption layer
  131. 131. Module (lib) <<ValueObject<<ValueObject <<ValueObject>> <<ValueObject <<ValueObject>> <<Service>>   <<SPI>> <<Service>>   <<API>> <<En7ty>>   <<Aggregate>> Module   ==   library Accès  aux   services   extérieurs
  132. 132. Module  ==   library Accès  aux   services   extérieurs
  133. 133. Hexagonal Architecture Scenario  test   data Adapters
  134. 134. Bounded Contexts
  135. 135. Bounded Contexts Il  n’est  pas  possible  de  convenir  du  sens  précis  des   mots  u7lisé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é.
  136. 136. Different MY activity is not the
  137. 137. Merci ! hFp://cathy313.centerblog.net/539-­‐bisounours
  138. 138. Wrap-up • Concepts & Messages – Subir -> Délibéré   – Intérieur Vs Extérieur   – Gérer ses dépendances   – Langage interne / externe   – DIP   • Exemples • Kata
  139. 139. Content • When not to go Hexagonal?   – Conformist – Facebook game – Too small (connector…)   ! • Advanced aspects   – The adapter pattern   – Tech ports diversity – 1 Adapter – many interfaces   – 1 interface – many adapters – Data push   – Session management   – Adapter as a module indeed
  140. 140. Content 2 Domain model as a Pure Functions (100% no Entity inside) vs as Aggregates ! -- The Repository pattern Reuse slides Hexagonal for a Bubble Context within a legacy ! Ports = surrounding legacy Adapters = repository / adapter ! Cloakroom / clandestine passenger patterns
  141. 141. Content 3 How to enforce? ! Discipline Maven multi modules, .Net projects Static analysis: JDepend rules, NDepend, Sonar plugins — Bounded Context Reuse slides ! Conformist vs ACL isolation Same language or not? ! Autonomous Components / Polyglot persistence ! Influence of sync vs async / push vs pull on the inside of the hexagon ! Examples? Living Documentation Convention (YES)? Annotation on packages? ! The Bounded Contexts / the Domain models vs the rest (ici un seul Bounded Context) ! Domain model -> inside Everything else - that implements something from the domain model -> at the right - everything else that only calls - > at the left !
  142. 142. Apply DDD! 153
  143. 143. http://www.lexicalscope.com/blog/category/patterns/
  144. 144. http://matteo.vaccari.name/blog/archives/154 Problem:  write  a  program  that   1.  Loads  a  set  of  employee  records  from  a  flat  file     2.  Sends  a  greetings  email  to  all  employees  whose  birthday  is  today     ! The  flat  file  is  a  sequence  of  records,  separated  by  newlines;  this  are  the  first  few  lines:   last_name, first_name, date_of_birth, email ! Doe, John, 1982/10/08, john.doe@foobar.com ! Ann, Mary, 1975/09/11, mary.ann@foobar.com ! The  greetings  email  contains  the  following  text:   Subject:  Happy  birthday!  Happy  birthday,  dear  John!     with  the  first  name  of  the  employee  substituted  for  “John”   ! 3.  REST  service  to  query  past  greetings   ! HINT:  today  is  a  tech  port!   ! ! +-----+-------------+----------+! | gui | file system | database |! |-----+-------------+----------+! | domain |! |------------------------------+ +--------------+! | presentation |! |--------------|! | domain |! |--------------|! | persistence |! +--------------+ Exercise Postgres Sql + Gui (+ myBatis ?) Audit et log dans le domain + Metrics

×