Langlebige Software: Eine Einführung in DDD Strategic Design (JUG Karlsruhe 24.10.2018)

Transcript

1. Langlebige Software Eine Einführung in DDD / Strategic Design JUG Karlsruhe, 24.10.2018
2. Manuel Zamora- Morschhäuser 2
4. Consult Plan Build Launch Run
5. Digitalisierung
6. #Neuland
9. Unklare Verantwortlichkeit Der Kollege ist schon länger krank Das traut sich keiner anzufassen „Ganz einfach“ „Politik“
10. Geschäftsprozesse
11. Unternehmen sind komplexe, adaptive Systeme* *Netzwerke unabhängiger Teilnehmer, die sich gegenseitig beeinflussen und das Gesamtsystem dabei nicht-deterministisches Verhalten an den Tag legt
12. Es geht nicht um „Software“
13. “Software development is a learning process, working code is a side effect“ Alberto Brandolini
14. Software ist ausführbares Wissen
15. Kosten Projektphase Analyse Modellierung Code Test Produktion
16. Up-Front Design Discovery
17. Passen die Prozesse in der Software- entwicklung zu dem benötigten Output „Wissen“?
18. Anforderungs- flüsterpost
19. Complexity: Essential / Accidental
20. https://www.monkeyuser.com/2018/architecture/
21. Komplexität Projektverlauf fachliche Komplexität CRUD- Architektur Optimal passende Architektur
24. Building software „driven by the domain“
25. Design Praktik Keine „Toolbox“
26. Ziele • Identifizieren des eigentlichen Ziels der Unternehmung • Komplexität in der Fachdomäne aufzeigen • Finden eines möglichst passenden und nützlichen Modells für Prozesse und Konzepte • Schaffung einer gemeinsamen Sprache • Keine „Übersetzung“ nötig zwischen Domänenexperten, Entwicklern (und Software) • Kontinuierliches Lernen und Verbessern des Modells • Entwickeln einer Software-Lösung, die das Domänenmodell ohne Veränderung umsetzt • Modularisierung anhand fachlicher Grenzen zur unabhängige Weiterentwicklung innerhalb • Strikte Trennung zwischen Fachlichkeit und Technologie • Langfristig veränderliche Software
27. Strategisches Design Techniken zum Entdecken und Modellieren einer komplexen Fachdomäne und ihrer internen und externen Zusammenhänge
28. Taktisches Design Werkzeuge zur Umsetzung einer langlebigen und veränderlichen Softwarelösung, die das Modell der Fachdomäne ohne Veränderung umsetzt
29. Domäne Ubiquitous Language Bounded Context Aggregates Context Maps Domain Events
30. Domäne Core Domain Supporting Domain Generic Sub-Domain
31. Mission Statement: „Wir möchten die günstigsten Anbieter von Fahrten in Europa sein“ Core Domain: Fahrstrecken, Preise, Effizienz Supporting Domain: Verkaufen von Tickets, Sitze reservieren Generic Subdomain: Zahlungsabwicklung, Inkasso Beispiel: Fernbusunternehmen
32. Ubiquitous Language
34. Ubiquitous Language Modellierte „Sprache“ die zwischen allen Teammitglieder verwendet und gleich verstanden wird
35. Ubiquitous Language Einheitlich nur innerhalb eines Bounded Contexts, nicht in der gesamten Organisation!
36. Bounded Context
37. Bounded Context Definition: Gültigkeitsgrenze für eine ubiquitäre Sprache
38. Bounded Context Innerhalb eines Kontexts hat ein Konzept aus der Domäne die gleiche Bedeutung
39. Bounded Context Beispiel: “Kunde“ in E-Commerce Domäne Authentifizierung: Email, Passwort, … Marketing: Interessen, Bestellverlauf, … Versand: Lieferadresse, …
40. Aggregate
41. Aggregate Aggregates entsprechen den Invarianten* des Domänenmodells * Regel(n) der Domäne, die alle zusammen immer gültig sein müssen
42. Aggregate Kleinstmögliches sinnvolles, eigenständiges, konsistentes Konzept aus dem Domänenmodell
43. Aggregate Beispiel: Warenkorb Regel: Die Summe im Warenkorb entspricht der Preise x Anzahl aller enthaltenen Produkte
44. Aggregate = Transaktionseinheit Jede Transaktion in einem Bounded Context verändert nur ein Aggregate auf einmal Konsistenzen zwischen Aggregates werden über Eventual Consistency (z.B. mithilfe von Domain Events) sichergestellt
45. Domain Event
46. Domain Event Beschreibt ein Ereignis aus der Fachdomäne, das an einem bestimmten Punkt in der Vergangenheit stattgefunden hat Domain Events sind Teil der Ubiquitous Language
47. Domain Event Beispiel: ProduktInWarenkorbGelegt (pid:1), ProduktAusWarenkorbEntfernt (pid:1)
48. Domain Event Wird jedes Ereignis eines Aggregates in der Domäne mithilfe von Events modelliert, kann der Zustand des Aggregates an einem beliebigen Zeitpunkt jederzeit über die Summe aller Events bis dahin berechnet werden
49. Context Maps
50. Context Maps Visualisiert alle Bounded Contexts eines Systems und ihre Beziehungen untereinander mit dem Ziel, eine ganzheitliche Übersicht zu vermitteln
51. A B Modellfluss Upstream Downstream Beziehungstyp Beziehungstyp Zugriffsfluss
52. A B Upstream Downstream Open Host
53. A B Upstream Downstream Open Host Anti Corruption Layer
54. A B Upstream Downstream Published Language Open Host
55. A B Upstream Downstream Partnership
56. A B Upstream Downstream Open Host Customer / Supplier
57. A B Upstream Downstream Open Host Conformist
58. A B Upstream Downstream K Shared Kernel
59. A B Upstream Downstream Seperate Ways
60. A B Big Ball of Mud
61. A B D E C Open Host ACL Customer / Supplier Customer / Supplier Open Host Conformist Partnership ACL Customer / Supplier
62. Context Maps visualisieren Conway‘s Law* * Organisationen, die Systeme entwerfen, sind auf Entwürfe festgelegt, welche die Kommunikationsstrukturen dieser Organisation abbilden
63. Starker Zusammenhang & geringe Kopplung
64. Event Storming
65. Event Storming Entdecken und modellieren wie die Domäne funktioniert, anhand der zeitlichen Abfolge von signifikanten Ereignissen
66. Wie kann man Event Storming einsetzen? - Kennenlernen der gesamten Fachlichkeit im crossfunktionalen Team, zB zu Projektbeginn - Identifizieren der Bounded Contexts - Modellieren eines komplexen Teilprozesses - Modellieren/Verbessern einer User Experience Journey - Beibringen der Fachlichkeit, z.B. beim On-Boarding von neuen Kollegen - Modellieren von jeder Art von Prozessen auch außerhalb der Softwareentwicklung, z.B. als Value Streams - Als Konversationsstarter
67. Was wird benötigt? - Möglichst große Modellierungsfläche (Optimal: Wände), die mit Endlospapier beklebt ist - Ganz viele Klebezettel mit verschiedenen Farben - Ausreichend viele Permanent-Marker - Klebematerial, um Linien ziehen zu können (z.B. Kreppband) - Flip-Chart o.ä. um Legenden festzuhalten - KEINE Stühle oder Tische - Teilnehmer – je nach Ziel des Workshops so divers wie möglich (Domänenexperten aus allen Abteilungen, Entwickler, Designer, PO, …) - Moderator - Ein Themengebiet zum Modellieren - Timebox
68. Domain Event Domain Event • Ereignis aus der Domäne • Orangenes Post-It • Verb in Vergangenheitsform
69. Zeit „Ergebnis“- Event
70. Zeit
71. Zeit Hotspot Risiko Idee / Gelegenheit
72. Zeit Mögliche Systemgrenzen Schlüsselevent
73. https://twitter.com/mariuszgil/status/1052179034065522693
74. External System Externes System • Hell-violettes Post-It
75. Actor Aktor • Kleines gelbes Post-it • Symbolisiert „Benutzer“ im Domänenmodell
76. Policy Regel • Violettes Post-It • Regel • Formuliert Bedingung für Ereignis • Oder auch zeitliche Steuerung („alle n Minuten“)
77. Command Kommando • Blaues Post-It • Anweisung bzw. Entscheidung eines Aktors
78. Read Model Zustand • Grünes Post-It • Information, die benötigt wird, um eine Entscheidung zu treffen / Anweisung zu geben • Berechnet aus Summe von Domain Events
79. Aggregate • Großes gelbes Post-It • Invariant aus dem Domain-Modell Aggregate
80. UI User Interface • Großes weißes Post-It • User-Interface, das zur Darstellung einer oder mehrerer Read Models verwendet wird
81. Command External System Aggregate Event Read Model UI Policy Command Aktor
82. Kunde Füge Artikel zu WK hinzu Warenkorb Artikel hinzugefügt Warenkorb Warenkorb Detailseite Artikel nicht verfügbar Nicht verfügbarer Artikel in WK? Entferne Artikel aus WK Artikel entfernt Lagerhaltung
83. Event Storming ist Mob Programming mit dem Kunden
84. Akzeptieren von fachlicher Komplexität – Software ist kein Selbstzweck „Continous Learning“ als Kernprinzip unserer Arbeit Accidental Complexity minimieren – There is no silver bullet Niemals über etwas diskutieren, was nicht an der Wand klebt
85. Vielen Dank für Ihre Aufmerksamkeit_ Manuel Zamora Architekturen & Technologie manuel.zamora@etecture.de
86. Literatur Domain Driven Design, Eric Evans Implementing Domain Driven Design, Vaughn Vernon Domain Driven Design Distilled, Vaughn Vernon Introducing Event Storming, Alberto Brandolini Langlebige Softwarearchitekturen, Carola Lilienthal