Modellierung der fachlichen Soll-Architektur 3.Schritt: Abgleich Ist- mit Soll-Architektur 4.Schritt: Priorisieren und Umbaumen Domain-Driven Transformation
Vertrag 4 Vertrag 7 1 Auto 5 Risiko 8 Auto 6 Rückkaufswert value 2 Leasing Rate Vertrag Verkauf Risiko- bewertung 2. Schritt: Modellierung der fachlichen Soll-Architektur
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 The Modularity Maturity Index (MMI)
Architektur: hohe Kohäsion & lose Kopplung Modul B Modul A Modul C User Interface User Interface User Interface Domain Model Application Domain Model Application Domain Model Application Lose Kopplung = So wenig Kopplung wie möglich!
von Containern vor ihrer Ankunft per LKW, Zug oder Schiff Einlagern und Umlagern durch Kräne und andere Fahrzeuge, die die Container im Yard bewegen Be- und Entladen vom Containerschiff
weniger Design: besser Modularität: schlecht • Schritt 1: Wiederentdecken der Fachdomäne mit DST und ES • Schritt 2: Modellieren der fachlichen Zielarchitektur • Schritt 3: Abgleich von Ist- und Soll-Architektur • Schritt 4: Prioritisierung und Durchführung der Umbaumaßnahme MMI 4-8 → Weg 1: 2) Strategische DDT Modularität: besser Design: besser Security + Infrastructure: höher Bugs: weniger
Strategische DDT Module B Module A Module C User Interface User Interface User Interface Domain Model Application Domain Model Application Domain Model Application Unser System
weniger Modularität: schlecht • Schritt 1: Wiederentdecken der Fachdomäne mit DST und ES • Schritt 2: Modellieren der fachlichen Zielarchitektur • Schritt 3: Abgleich von Ist- und Soll-Architektur • Schritt 4: Prioritisierung und Durchführung der Umbaumaßnahme MMI 4-8 → Weg 2: 1) Strategische DDT Modularität: besser Security + Infrastructure: höher Bugs: weniger Design: schlecht Design: schlecht
weniger Design: besser Modularität: schlecht • Schritt 1: Wiederentdecken der Fachdomäne mit DST und ES • Schritt 2: Modellieren der fachlichen Zielarchitektur • Schritt 3: Abgleich von Ist- und Soll-Architektur • Schritt 4: Prioritisierung und Durchführung der Umbaumaßnahme MMI 8-10 → Strategische DDT Modularität: besser Design: besser Security + Infrastructure: höher Bugs: weniger
Modellierung der fachlichen Soll-Architektur 3.Schritt: Abgleich Ist- mit Soll-Architektur 4.Schritt: Priorisieren und Umbaumen Domain-Driven Transformation
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. Nach Unterschieden in der Verwendung und Definition von Schlüsselkonzepten in der Domäne Nach Abteilungen in der Organisation bzw. Gruppen von Domänenexperten
in der Domäne Zerlege die Software entsprechend in bounded contexts, die Grenzen bilden für domain-orientierte Teile in der Software and in der Teamorganisation Ziel: Jedes Team ist Experte für eine Subdomäne Domain Software System Bounded Context A Bounded Context B Team A Team B Bounded Context C Team C Subdomain A Subdomain B Subdomain C
Domänen müssen in Subdomänen mit kleineren Modellen aufgeteilt warden ▪ Separate Modelle ▪ erlauben unabhängige Änderungen ▪ setzen eine kleinere Menge von Anforderungen um (hohe Kohäsion) ▪ definieren klare Grenzen (lose Kopplung) ➔ Jede Subdomäne sollte ein Modell enthalten, das so klein ist, dass es von einem Team beherrscht werden kann.
Story verstehen + Subdomänen finden Installiert Visual Code (oder ähnliches) Legt ein neues Projekt an aus https://github.com/lilienth/ddd-banking-example Geht auf die Webseite von egon.io Öffnet die Domain Story aus Hands-on Legacy Code/domainstory Überlegt Euch mögliche Subdomänen Zeichnet eine Context Map
Sourcecodes: Größen von Methoden, Klassen, Packages Testabdeckung Zyklomatische Komplexität Duplizierter Code EINSATZ VON TOOLS Architekturanalyse-Tools analysieren die Komplexität des Design, der Architektur: Schichtenverletzungen Zyklen zwischen Modulen, Klassen, Packages Abhängigkeiten zwischen Modulen, Klassen Kohäsion und Kopplung
Technical layering Domain layering Drei Verletzungen, die leicht zu beheben sind Dieselbe Komponenten wie links Eine Komponente verursacht viele Probleme
Typische Metriken: LOC pro Methode, Klasse, Package, Modul Duplicated Code Cyclomatic complexity ▪ Ist das System ausgewogen auf den verschiedenen Ebenen? ▪ Welche Code-Teile fallen wegen ihrer Größe besonders auf? Anti-Pattern „Godclass“
Laded den Sonargraph Architect: www.hello2morrow.com Registrieren und Testlizenz erfragen Öffnet im Sonargraph den Sonargraph-Ordner aus Git Drückt auf Refresh und öffne den Exploration View (rechte Maus auf legacy-code) Lege im Reiter “Files” eine neue Architectural View mit dem Namen “BoundedContexts” an Lege über das Kontextmenü des Views zwei neue Artifacte für die beiden BCs an (outgoing relaxed) und sortiere die Klassen des Systems zu Welche Verletzungen finden wir? Welche Refactorings sollten passieren?
DIE MIKRO ARCHITEKTUR User Interface Domain Application Layering by patterns Bounded Context Repository Factory Model View Controller ValueObject Service Entity/Aggregate
Typs der Fachdomäne. ▪ Symbolisieren bei Gleichheit denselben Wert. ▪ Sie werden vom Anwender nicht „bearbeitet“, sondern nur weiterverarbeitet. ▪ Können aus anderen Value Objects bestehen werden. VALUE OBJECTS ValueObject 2,5 ValueObject 2,5 ValueObject 5/2 ValueObject 2½ ValueObject zwei- einhalb
Sie werden vom Anwender „bearbeitet“. An ihnen schlagen sich die Ergebnisse seiner Arbeit nieder. Beispiel Entity „Peilplan“: Der Nautiker markiert eine Untiefe im Peilplan. Besitzen eine zustandsunabhängige, unveränderliche Identität. Haben einen klar definierten Lebenszyklus. Besitzen einen (meist veränderlichen) Zustand. Beschreiben ihren Zustand mithilfe von Value Objects. Auch: Business Objects / Domain Objects → NICHT ZU VERWECHSELN mit dem Begriff "ENTITY" aus dem Entity-Relationship-Modell! ENTITIES
{ // ... public int balance() { return _balance; } public void setBalance(int amount) { _balance = amount; } } Can I set the Balance to a negative amount? In EUR or GBP or…?
Amount { private final int _amount; private final Currency _currency; private Amount(int amount, Currency currency) { _amount = amount; _currency = currency; } public Amount add(Amount otherAmount) { return Amount.of(_amount + otherAmount._amount, _currency); } public Amount substract(Amount otherAmount) { return Amount.of(_amount - otherAmount._amount, _currency); } The new value object type only behaves correctly, if the currency is the same! Problem will be resolved later ☺
VERSION public class Account { private Amount _balance; public Amount balance() { return _balance; } public void setBalance (Amount amount) { _balance = amount; } } Now we can use the amount type
uns die fachlichen Klassen anschauen Was für Value Objects könnte Account noch brauchen? Braucht Credit auch Value Objects? Hands-on: Welche Value Objects brauchen wir insgesamt? Baut einen neuen Value Object ein! Wo wollen wir die Value Objects einsortieren?
ANEMIC DOMAIN MODEL ▪ Die Schnittstellen der Klassen im Domänenmodell bestehen aus getters und setters ▪ Die Fachlichkeit befindet sich in den Services oder der UI und nicht in den Entities ▪ Es gibt viele Util, Helper and Manager Klassen
DRAFT public class Account { private Amount _balance; public Amount getBalance() { return _balance; } public void setBalance(Amount amount) { _balance = balance; } } ✘ Bad: The account balance can be set to any value
VERSION public class Account { private Amount _balance; public Amount balance() { return _balance; } public void deposit(Amount amount) { _balance = _balance.add(amount); } public void withdraw(Amount amount) { _balance = _balance.substract(amount); } } Better: Operations with domain- specific behavior and names
BY CONTRACT USING “ASSERT” public class Account { // ... public void withdraw(Amount amount) { // _balance >= amount _balance = _balance.subtract(amount); } } Assertion using keyword “assert”
BY CONTRACT USING “ASSERT” public class Account { // ... public void withdraw(Amount amount) { assert amount.isLessOrEqual(balance()); _balance = _balance.subtract(amount); } } Assertion using keyword “assert”
OF CONFIDENTIALITY „If you delegate, delegate fully!“ „Don‘t talk to a stranger!“ (also: "shy code") student.getRecord().getExamEntry("SE2/2006").addResult(93); Record Student ExamEntry SE2/2006 getRecord() getExamEntry(String) addResult(int) ✘ Here the Law of Demeter is violated! ▪ If you "implement" traversing object nets, you couple the code too strongly to a structure → bad changeability!
OF CONFIDENTIALITY Do not use the objects of your objects. Do not delegate and do not care how and with what an object works. "Tell, don‘t ask" student.scored("SE2/2006", 93); Record Student ExamEntry SE2/2006 scored(String,int) getExamEntry(String) addResult(int) Here the Law of Demeter is followed!
wir uns noch einmal die Domänenklassen an Sind Credit und Account reiche Domänenklassen? Ist das law of demeter verletzt? Hands-on Was sind aus Eurer Sicht die Probleme? Wie sollten wir die Klassen refactorn? Wenn Zeit ist, dann baut das System um!
Schritt eine Rolle Eins zu eins Zusammenhang zwischen Rolle und Arbeitsergebnis in einem Status Klare zeitliche Reihenfolge für die Schritte Klare Übergänge zwischen den Schritten Arbeitsergebnisse werden übergeben Arbeitsergebnisse sind Grundlage für den nächsten Schritt
Verschiedene Rollen arbeiten gemeinsam an einem oder mehreren Geschäftsobjekten – es gibt keine 1-zu-1 Beziehung zwischen Rollen und Geschäftsobjekten keine Übergabe von Arbeitsergebnissen Keine klare Reihenfolge der Schritte
für Autos oder Maschinen und Anlagen Beobachten und Überwachen in einem Leitstand, z. B. Überwachen von Anlagen, Logistikprozessen, Verkehrsfluss oder die Beeinträchtigung von Lieferketten Planung von größeren Ereignissen (Veranstaltungsmanagement) Softwareentwicklung in agilen Teams Computerspiele, bei denen viele Spieler in einer Welt zusammentreffen
Verschiedene Rollen arbeiten gemeinsam an einem oder mehreren Geschäftsobjekten – es gibt keine 1-zu-1 Beziehung zwischen Rollen und Geschäftsobjekten keine Übergabe von Arbeitsergebnissen Gemeinsames Aushandeln eines Plans Mehrere Parteien aus unterschiedlichen Unternehmen
Aushandeln von Schiffsreiseplanungen zwischen Reedereien und Häfen Das Aushandeln der Art, Lieferung und Wartungszyklen für Großgeräte zwischen Disponenten und Kunden Das Aushandeln der langfristigen Baumaßnahmenplanung zwischen Verwaltung und Bauantragsstellern Manche Spiele fallen auch in diese Kategorie, wenn sie auf Aushandlungsprozessen basieren
wps
lovee
mana_takada
hayat01sh1da
seike460
taigakono
ryunen344
chobishiba
narihara
kamomeashizawa
ivry_presentationmaterials
sakawe_ee
maltzj
tammyeverts
mongodb
irinanazarova
eitanlees
garrettdimon
lemiorhan
tenderlove
kastner
skipperchong
chriscoyier
marcelosomers
