Vortrag VI Stichpunkte

Vom Big Ball of Mud zu DDD Vortrag 11.01.19 - Christian Nockemann

Ben: Neues neben das alte bauen - 2 speed IT - Problem wieder zusammenführen der Lösungen

Brownfield ist die Regel, vor allem im Beratungsgeschäft

Beratung findet statt wenn etwas nicht in Ordnung ist

Kompromissse erforderlich, Kompromisse nicht immer optimal

inkrementelle Verbesserung anstreben, nciht aufgeben, big ball of mud entzerren

DDD häufig unbekannt, auch in den Entscheidungsebenen wie Argumentieren für DDD: kleine Komponenten werden schon lange angestrebt

Visualisieren der Problemstellung, Dependency Hell

Zirkuläre Abhängigkeiten -> werden häufig abgebildet, anstatt diese zu beheben
Zirkuläre Abhängigkeiten stellen Problem dar

langsame Builds, schlechte skalierbarkeit - hohe kosten für releases, argument für ddd

software ist fragil, jede Änderung ist kritisch

Was wollen wir? Robustheit und Änderbarkeit

Software ist nie fertig -> Änderbarkeit ist kritisches Thema und Wettbewerbsvorteil

SOLID-Prinzipien
	DDD unterstützt das Open-Close Prinzip
		Komponenten die fertiggestellt sind sollten geschloßen gegenüber Modifikationen sein, aber offen für Änderungen
		
Unabhängige und Cross-funktionale Teams -> Grundvoraussetzung für agiles Arbeiten
	Häfuig Ursache Wirkungsvertauschung -> Unternehmenskulutr muss sich ändern für agilität, technische Voraussetzungen müssen gegeben sein (kein legacy monolith)
	
Agilität

Grundlagen Start: IST Zustand

Exkurs: Dependency Disziplin ist enorm wichtig, damit nciht mit kleinen Schritten wieder ein Monolith entsteht, Tests dafür sind möglich

Zwischenziel:
den Tatsachen ins Auge blicken

Umwandeln in viele Komponenten mit Netzwerk zu viele Komponenten mit "shared Kernel"

Erlaubt es Teile aus dem shared Kernel herauszuziehen und den Shared Kernel Schrittweise zu schrumpfen

NOTWENDIGE BEDINGUNG:

Priorität: Sicherung des Betriebs!

Daher: Atomare Schritte! Nur einzelne Schritte vornehmen

Integrationstests durchführen
Kleinteilige Unittest in der Realität nur Schwer, End to End Test aber realistisch

RÜCKWärtskompatibilität
Schnelles Rollback, fachliche Kernlogik muss in der alten und der neuen Welt lauffähig sein (wenigstens für Übergangsphase)

Konkrete Schritte: keine zeitliche Abfolge:

Abhängigkeitszirekl beheben: Komponenten Aufsplitten in API und Implementierungsteil

Onion Architektur: fachlicher Kern sollte frei sein von jeglicher Frameworklogik, Ringe drumherum immer mehr hinzufügen

Strangler Pattern:

Getrennte Domänen: Es gibt häfig keine fachlichen Kontexte - finden!

Neuer Technologiestack

Seperation of Concerns: Softwarekomponenten müssen innerhalb einer Komponente nur mit einem fachlichen Belang beschäftigen

Wichtiger Punkt: Wenn keine Dokumentation vorhanden -> Dokumentation anlegen. Dokumentation des IST-Zustands

1. Etappenziel

   wohl strukturierter Monolith

   fachliche silos statt technischer schichten! -> vertikale architektur statt schichten

Onion-Architecture

Kern der fachlcihen Domäne: Domänenmodell - technologiefrei - plain java -damit technologiewechsel möglich

Umhüllt von Domain Services - klein halten - logik

umhüllt von application services - keine Businesslogik, verschalten Schritte um fachlichen Prozess bazubilden

Aufteilung von API und Impl. Zirkuläre Abhängigkeiten können nicht so leicht gelöst werden

Wiederverwendung von Typen DRY(dont repeat yourself) führt schnell zu zirkulären abhängigkeiten

Extraktion eines Domänenmodells

Aus Code

Code wird in richtige Objektorientierung überführt (ValueObjects, Entitys), dann anlegen von Aggregates und Domänenservices

Schritt zurücktreten (vorher alles in der alten Welt umsetzbar als Vorbereitung) Aussuchen eines neuen Technologiestacks

Domänen identifizieren Interviews Was wird gemeinsam geändert? Engmaschige Abhängigkeitsnetzte -> Domäne? Wer arbeitet woran?

spätestens jetzt: shared Kernel verkleinern -> Komponenten in Domänen verschieben

Endergebnisse: Domäne im Überblick

	UI -> API
	
	Kern <- API -> Repository (technisch)
	
	Repository (technisch)

	Anti Corruption Layer ACL zu anderen Domänen -> Dependency Disziplin

Strangler Pattern - Schrittweise Migration

-> An dieser Stelle: Voraussetzungen für einen Monolithen geschaffen;

Budget für Behebung technischer Schulden muss bei der Weiterentwicklung berücksichtigt werden -> MS & Monolithen