Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Ddd brutto sporco e cattivo

La mia presentazione su Domain-Driven Design in ambiente legacy, ri-editata dopo il Codemotion di Roma.

  • Login to see the comments

Ddd brutto sporco e cattivo

  1. 1. DDDBrutto,Sporco eCattivo@ziobrando
  2. 2. Obiettivo #1Arrivare a DDDnon partendo dalfoglio bianco...
  3. 3. Obiettivo #2Arrivare a DDD inmaniera nonprescrittiva
  4. 4. Do you really need me?
  5. 5. CheckpointQuando fare DDD?- Problema complesso- Aspettative elevate
  6. 6. Anti-pattern Voglio fare DDDNon lo conosco molto bene... ...quindi lo applico ad un problema semplice Non ne vedo i vantaggi ...DDD non serve.
  7. 7. Sbagliato
  8. 8. Non si impara in pianura
  9. 9. Non è questo il nostro lavoro
  10. 10. C’è chi lo sa fare meglio
  11. 11. La rete di protezione ✓Ambienti ✓Build script ✓Test suite ✓Database privato ✓Fixtures
  12. 12. Strumenti
  13. 13. Professionisti
  14. 14. Strumenti adeguati
  15. 15. Anche nelle peggiori condizioni
  16. 16. Infermiera, mi passa Quello a punta? Sì,quello con lapunta un po’
  17. 17. Strumenti
  18. 18. Precisione
  19. 19. Aspirina Anticoncezionale
  20. 20. Linguaggio
  21. 21. Siete
  22. 22. Checklist Strumenti? --> Strumento. (Sempre e solo quello) Precisione? --> “Quando sei in stato 12 il campo MRKT_NFLD può valere solo B o K” Linguaggio? --> :-( avanscoper ta
  23. 23. Data-based integration
  24. 24. Qual è ladifferenza tra i maiali e le applicazioni?
  25. 25. Checklist data-based Siamo in grado di sapere... Quale applicazione è responsabile della struttura del dato? Quale requisito ne ha influenzato la definizione? E’ ancora valido? È valido nel mio contesto? Quali applicazioni utilizzano quel dato? Quali conseguenze avremo cambiandone la struttura? avanscoper ta
  26. 26. Obiettivo #1Arrivare a DDDnon partendo dalfoglio bianco...
  27. 27. Soluzione #1Mettere da parteil casino ecominciare dalfoglio bianco...
  28. 28. Quale problema vogliamo risolvere?
  29. 29. Uno
  30. 30. Il nostro
  31. 31. Complessità Dominio del Nostro PROBLEMA SOLUZIONI precedenti 15%85%
  32. 32. Il nostro problema Altro contesto Altro contesto I d at i d a c o n di v id Il nostro contesto ere I nos t r i d at i Il nostro database
  33. 33. THIS DATABASE IS MY DATABASE TRESPASSERS WILL BE SHOT SURVIVORS WILL BE SHOT AGAIN
  34. 34. Dev: “Detto così è semplice...”
  35. 35. DDD serve arisolvere problemicomplessi,
  36. 36. DDD serve arisolvere problemicomplessi,NON a complicareproblemisemplici.
  37. 37. Strategie pergestire gli zombi
  38. 38. Un bel recinto...
  39. 39. A Romolo!! Efamme fà ‘sta
  40. 40. A Romolo!! E famme fà ‘staNone
  41. 41. A Romolo!! E famme fà ‘staNone Eddai ...è di sola lettura...
  42. 42. BoundedContext
  43. 43. Anti-Corruption Layer Our Context ACL da ry Other Context u ndar y ex t boun bo con t co n te x t <<Entity>> MyEntity Attributo Attributo <<Service>> Componente ContactService getContattiUnici(…):List<Contatto> ContactService <<Value Object>> ContattoAttributoAttributo
  44. 44. Anti-Corruption Layer Our Context ACL da ry Other Context u ndar y ex t boun bo con t co n te x t <<Entity>> MyEntity Attributo Attributo <<Service>> Componente ContactService getContattiUnici(…):List<Contatto> ContactService <<Value Object>> ContattoAttributoAttributo Il modello come dovrebbe essere
  45. 45. Anti-Corruption Layer Our Context ACL da ry Other Context u ndar y ex t boun bo con t co n te x t <<Entity>> MyEntity Attributo Attributo <<Service>> Componente ContactService getContattiUnici(…):List<Contatto> ContactService <<Value Object>> ContattoAttributoAttributo La componente Il modello come legacy, con i dovrebbe essere suoi guai
  46. 46. Anti-Corruption Layer Our Context ACL da ry Other Context u ndar y ex t boun bo con t co n te x t <<Entity>> MyEntity Attributo Attributo <<Service>> Componente ContactService getContattiUnici(…):List<Contatto> ContactService <<Value Object>> ContattoAttributoAttributo La Qui risolviamo il componente Il modello come casino, anche con legacy, con i dovrebbe essere le maniere forti suoi guai
  47. 47. ...e dentro il nostroBounded Context...
  48. 48. Il modello ideale
  49. 49. Non è poi cosìimportante...
  50. 50. Compliance
  51. 51. Non c’ènessunamedaglia...
  52. 52. ma forse...http://www.youtube.com/watch?v=zDZFcDGpL4U
  53. 53. DDD patternsa supporto di riscritture frequenti
  54. 54. DDD comearchitettura di supportoall’evoluzione
  55. 55. meglio dotarci diadeguati strumenti di supporto alla progettazione
  56. 56. Lavagne
  57. 57. CRC Cards
  58. 58. P.O.: “Davvero possiamo fare questo?”
  59. 59. Dev: “Dobbiamo mettere uno strato di validazione per evitare che i dati sporchi entrino nel sistema”
  60. 60. Davvero?
  61. 61. La validazione complessa è uno smell
  62. 62. Dati (quasi) uguali <<Entity>> <<Entity>> FatturaPreview Fattura importoimporto clientecliente statomodifica emetticonvalida registraPagamento Comportamento differente
  63. 63. Multiple models
  64. 64. Archetipifrequenti
  65. 65. 3 archetipi? Costruzione collaborativa Topic+Conversation Facebook, Basecamp, Github Esecuzione Macchina a stati, Commands TrackingLogging, Auditing, Datawarehouse, Eventi
  66. 66. E il DBA che dice?
  67. 67. DBA: “Mi aspettavo che fosse stata definita per bene la struttura del database, una volta per tutte”
  68. 68. ...
  69. 69. Prima idea...
  70. 70. Può una componente progettata prima di una applicazioneessere adeguata alle N applicazioni successive?
  71. 71. Ostacoli
  72. 72. Per poter interagire conil sistema X devi guardarti le spalle
  73. 73. Ci sono delle f***utestored procedure che girano ogni 10 minuti
  74. 74. Nessuno saesattamente come funzionino
  75. 75. Nessuno le ha mai Nessuno sa cambiate ed è tornato vivoesattamente come per raccontarlo funzionino
  76. 76. Hrmpf
  77. 77. Rischio...
  78. 78. Mi raccomando, copriti quando Ti sei messo la Chiudi la canottiera?porta a chiave, quando esci!
  79. 79. Ansia
  80. 80. Carico cognitivo Quante cose devo sapere prima di toccare il codice?
  81. 81. Possiamo essere ignoranti e produttivi allo stesso tempo?
  82. 82. Transaction management? Presentation Layer Application Layer Domain Layer Infrastructure Layer pi em D DD es gli de % 99
  83. 83. Repository & SRP <<factory>> OrderFactory createEmpty() Application Layer creates Domain Layer <<Entity>> <<Facade>> Order Application Facade price createOrder(…) customer delivery(order_ID, …) delivery() Crea il contesto e lo passa al repository <<Repository>> opens / closes OrderRepository save(Order, Context) findById(id, Context) Riceve il contesto uses transazionaleIl Repository effettua le dalle sternooperazioni di aggiunta e/o <<ORM>>rimozione dal contesto, ma è Contextlapplication layer ad invocare +saveChanges()saveChanges() Infrastructure layer
  84. 84. Non siaccettanocaramelledaglisconosciuti
  85. 85. ...mettiamo una tabella condivisa...
  86. 86. Ooops...
  87. 87. Non siaccettanocaramelledaglisconosciuti
  88. 88. Non si accettanocaramelle
  89. 89. Motivazioni
  90. 90. Infanzia difficile
  91. 91. Infanzia difficile Persona nome cognome numeroTel Studente ProfessorenumeroMatricola anzianità
  92. 92. Dimostrami diessere una Persona...
  93. 93. ...Stampati!
  94. 94. Infanzia difficile
  95. 95. Infanzia difficile Persona nome cognome numeroTel Studente ProfessorenumeroMatricola anzianità
  96. 96. Non stanno insieme! ...e non è colpa dell’ORM
  97. 97. Ogni regola architetturaleche comincia con “ogni” è sbagliata!
  98. 98. Conseguenze
  99. 99. Vedi, il mondo sidivide in due categorie: chi èin un bounded context, e chi scava...
  100. 100. Tu ...scavi
  101. 101. Stime
  102. 102. Stime
  103. 103. StimeEvoluzioni “esplorative”
  104. 104. StimeEvoluzioni “esplorative”Legacy “vaso di Pandora”
  105. 105. Ignorance based planning 100% 90% 80% B re a kt 70% h ro u g h Ignorance 60% 50% 40% Ignorance 30% 20% 10%
  106. 106. Gold plating?
  107. 107. Si, ma come faccio a sapere se sto facendo DDD?
  108. 108. Sto veramente facendo Prodotto migliore delle aspettative Non abbiamo paura di riscriverne dei pezzi Ci stiamo divertendo avanscoper ta
  109. 109. domande?
  110. 110. domande?Sul serio, potete farle...
  111. 111. DDD, CQRS and Event Sourcing Bologna 16-17 aprile 2012 http://avanscopertacqrstraining15042012.eventbrite.com/ Advanced CQRS Workshop Bologna 18-20 aprile 2012 http://avanscopertacqrsworkshop18042012.eventbrite.com/avanscopert © Alberto Brandolini 2009
  112. 112. Grazie@ziobrandoalberto.brandolini@avanscoperta.it

×