The joy of multiple models
3 gefällt mir603 aufrufe
Das Dokument erläutert, wie man eine monolithische Softwarearchitektur mithilfe von Domain-Driven Design (DDD) in separate, handhabbare Module aufteilt. Es wird erklärt, dass jedes Team an sein eigenes Domänenmodell arbeiten kann, indem es Grenzen und kontextspezifische Definitionen berücksichtigt. Außerdem wird auf die Wichtigkeit von einer klaren Ubiquitous Language und das Vermeiden von anämischen Domain-Modelle hingewiesen, um die Wartbarkeit und Robustheit des Systems zu gewährleisten.
The joy of multiple models
- 1. WPS - Workplace Solutions GmbH //// Hans-Henny-Jahnn-Weg 29 //// 22085 HAMBURG The joy of multiple models Wie man einen Monolithen mit DDD aufschneidet Dr. Carola Lilienthal, cl@wps.de, @cairolali www.wps.de
- 2. @cairolali Dr. Carola Lilienthal Geschäftsführerin cl@wps.de www.wps.de +49 40 229 499-0 +49 40 229 499-299 +49 170 184 77 11 Diplom-Informatikerin @cairolali @cairolali cl@wps.de www.llsa.de
- 3. @cairolali Software- Architektur Domain Storytelling Arbeitsplatz der Zukunft Individual- software Business-Software, die Spaß macht! WPS – Workplace Solutions GmbH
- 5. 463 tangled classes belonging to 10 different components
- 6. @cairolali
- 8. Team Head Team Tail Team Body Team Leg
- 9. Team Head Team Tail Team Body Team Leg
- 10. Team Head Team Tail Team Body Team Leg
- 11. Team Head Team Tail Team Body Team Leg
- 12. Team Emma Team Berta Team Erna Team Lisl
- 13. @cairolali DIE DOMÄNE IN DER SOFTWARE IST EIN MODELL ▪ Eine interne Repräsentation der betrachteten Domäne ▪ Ausgehend von der Domäne werden die Kernelemente: ▪ Organisiere ▪ Systematisiere ▪ Zerlege in Bestandteile ▪ Gruppiere diese Bestandteile in Module
- 14. @cairolali JEDER BOUNDED CONTEXT HAT SEIN EIGENES MODELL ZIEL: ▪ Jedes Team kann an seinem eigenen Domänen-Modell arbeiten ▪ Man kennt seine Grenzen ▪ Man bleibt in seinen Grenzen
- 15. @cairolali DAS GROSSE VEREINHEITLICHTE MODELL ▪ Umfasst die vollständige Domäne eines Unternehmens ▪ Ein nicht erreichbares Ideal ▪ Oft nicht lohnenswert anzuvisieren ➔Hoher Koordinationsaufwand in Teams ➔Führt oft zu einem big ball of mud
- 18. @cairolali WIE SCHNEIDE ICH MEINE DOMÄNE? ▪ Nach Abteilungen in der Organisation bzw. Gruppen von Domänenexperten ▪ Nach Unterschieden in der Verwendung/Definition von Schlüsselkonzepten in der Domäne ▪ Nach Grenzen im Geschäftsprozess, die die Domänenexperten beschreiben ▪ Information läuft in eine Richtung ▪ Prozesse werden in unterschiedlichen Rhythmen ausgeführt ▪ Prozesse werden von verschiedenen Triggern ausgelöst.
- 19. @cairolali
- 22. @cairolali Einmal pro Woche Trigger Trigger Immer wenn ein Kunde kommt
- 23. @cairolali Einmal pro Woche Trigger Informationsfluss Trigger Immer wenn ein Kunde kommt
- 24. @cairolali Einmal pro Woche Informationsfluss Trigger Immer wenn ein Kunde kommt Abteilung Kinomanagement Abteilung Kartenverkauf Trigger
- 25. @cairolali Einmal pro Woche Informationsfluss Trigger Trigger Immer wenn ein Kunde kommt Abteilung Kinomanagement Abteilung Kartenverkauf
- 26. @cairolali LIVING IN A BOX – BOUNDED CONTEXT → Jedes Modell bekommt einen Kontext ▪ Kontext = Grundsätzliche Voraussetzungen, damit Begriffe eine bestimmte Bedeutung erhalten ▪ Wird ein Modell aufgespalten, so ist für jedes Teilmodell eine Kontextdefinition erforderlich
- 33. @cairolali TAKTISCHES UND STRATEGISCHES MODELLIEREN Strategisches Modellieren (im Großen) ▪ Teile die Domäne in getrennte Bounded Contexts auf ▪ Jeder BC hat seine eigene ubiquitous language und sein eigenes Domänenmodell Taktisches Modellieren (im Kleinen) ▪ Innerhalb eines Bounded Context ▪ Ubiquitous Language als Grundlage ▪ Building Blocks: Entity, Value Object, Aggregate, Service, Repository, Factory
- 34. @cairolali BUILDING BLOCKS = MUSTER FÜR DIE MIKRO ARCHITEKTUR User Interface Domain Application SchichtungdurchMuster Bounded Context Repository Factory Model View ValueObject Service Entity/ Aggregate Controller
- 35. @cairolali
- 36. @cairolali BUILDING BLOCKS Wurzel-Entity Entity Entity Entity Entity VO VO VO VO VO VO VO VO VO VO VO VO Aggregate Service
- 37. @cairolali MAKRO ARCHITEKTUR FAST OHNE VERLETZUNGEN
- 38. @cairolali Problem A Problem B CHAOS IN DER MIKRO ARCHITEKTUR ◼ 98% aller Klassen kennen 10 andere Klassen ◼ „Problem A“ braucht 21 Klassen und wird von 49 Klassen verwendet ◼ „Problem B“ braucht 63 Klassen und wird von 18 Klassen verwendet ◼ 30% aller Klassen in Zyklen ◼ 60% aller Packages in Zyklen
- 39. @cairolali WAS WIR NICHT BAUEN WOLLEN ✘ ANEMIC DOMAIN MODEL ▪ „blutarme“ fachliche Objekte ▪ Schnittstelle ohne Aussagekraft ▪ aus Gettern/Settern ▪ Viele String Parameter ▪ Eigentliche Fachlichkeit außerhalb Entities + Value Objects in Services oder im UI ▪ Viele Util, Helper und Manager Klassen
- 40. @cairolali ANEMIC → FEHLENDE ROBUSTHEIT ▪ Designschulden ▪ Unklarer, schwer verständlicher Entwurf ▪ Verteilte Fachlichkeit ▪ Copy & Paste - Programmierung → Teure Wartung → Duplizierter Code → Viele Refactorings → Schlechte Testbarkeit
- 41. @cairolali GROSSE ZYKLEN VERSCHMUTZEN DAS SYSTEM 119 Klassen aus 4 Komponenten + 28 weitere Klassen
- 42. @cairolali GROSSE ZYKLEN VERSCHMUTZEN DAS SYSTEM 327 Klassen aus 8 Komponenten brauchen sich gegenseitig
- 43. @cairolali MODULARITY MATURITY INDEX (MMI) 612.869 LOC 14.756.435 LOC 252.062 LOC 804.093 LOC 543.388 LOC 1.035.668 LOC 486.358 LOC 175.258 LOC 42.311 LOC 193.383 LOC 643.466 LOC 245.754 LOC 2.890.204 LOC 141.696 LOC 512.086 LOC 9.988.363 LOC 200.591 LOC 922.949 LOC 22.658 LOC 663.862 LOC 3.270.188 LOC 1.521.357 LOC 0 2 4 6 8 10
- 45. @cairolali KONFERENZEN Germanys first DDD conference
- 46. Schulungen zu Architektur und Domain-Driven Design Architekturanalyse mit IhremTeam wps.de
- 47. @cairolali Dr. Carola Lilienthal Geschäftsführerin cl@wps.de www.wps.de +49 40 229 499-0 +49 40 229 499-299 +49 170 184 77 11 Diplom-Informatikerin @cairolali @cairolali cl@wps.de www.llsa.de Vielen Dank für Ihre Aufmerksamkeit!