Systemmigration mit Domain Driven Design

Softwareprojekte finden die meiste Zeit nicht auf der grünen Wiese statt. Gerade in der jetzigen Zeit der immer beschleunigteren Digitalisierung, sind viele in die Jahre gekommene Systeme an ihre Kapazitätsgrenzen angelangt oder durch technologische Sackgassen nicht mehr in der Lage, den modernen Anforderungen Rechnung zu tragen. Komplexe bis chaotische Komplexitätslevel tun ihr übrigens um ein hohes Risiko für eine Organisation darzustellen.

Dieser Vortrag gibt einen Einblick in die Herangehensweisen, die Herausforderungen und Lösungsansätzen um Altapplikationen zu modernisieren und zukunftsfähig zu machen. Dabei werden organisatorische Rahmenbedingungen und architekturelle Analysen zusammengeführt, um einen Migrationspfad zu erarbeiten. Als großes Hilfsmittel hat sich dabei Domain Driven Design und darauf aufbauende Self Contained Systems etabliert.

Transcript

1. SYSTEMMIGRATION MIT DDD EINE KLEINE GESCHICHTE VON KOMPLEXITÄT
2. 2 Search Eines Mittwoch morgens… Shopping Cart Delivery Payment
3. 3 Eines Mittwoch morgens… Search Shopping Cart Delivery Payment
4. Schaue ich mir mal an Eine Stunde später UI Backend Master Data Billing Persistence Wann war das genau? In welchem Prozessschritt? Trat das schon mal auf? Welche Abteilung war das? Wird im “Backend” sein. Da passieren die meisten Fehler… Ich geb das mal weiter
5. Zwei Tage später UI Backend Master Data Billing Persistence Hmpf! Der Fehler war doch bei uns in MasterData! Das dauert leider etwas. Da müssen wir erst mal analysieren. Ist nicht ganz trivial
6. Noch ein Tag später UI Backend Master Data Billing Persistence Hm. Ich finde gerade nichts in der Doku. Kannst du mir sagen, was hier im Delivery eigentlich passieren soll? Ouh. Da musst du Sabine aus dem Produktmanagement fragen. Ich bin ja im Fulfillment. ?
7. Shopping Cart 7 Divergente Sicht auf die Dinge Delivery Suche Payment UI Backend Master Data Persistence Billing technische Blöck Domain-Blöcke Was ist da los?
8. 8 Search Shopping Cart Delivery Payment Kategorie- Management Rechnungs- wesen Produkt- Management Marketing IT Fullfillment ? Was ist da los? Divergente Sicht auf die Dinge. Auch aus organisatorischer Sicht.
9. Conway’s Law Conway’s Law “Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.” - Melvin Edward Conway
10. Conway’s Law Conway’s Law Kategorie- Managemen t Rechnungs- wesen Produkt- Managemen t Marketing IT Fullfillment Erweitert
11. Technische Komplexität Plan vs. Realität oder … “Was zur Hölle… ?!” common lib Angular 1 UI Vue UI SAP Gateway SAP Master Data products process engine
12. Fachliche Komplexität Nicht jede Anforderung macht Sinn class Customer ( val vorname: String, val nachname : String, val strasse: String, val geburtstag : String?, val hausnummer : Int, val hausnummerZusatz : String, val plz: String, val ort: String ) class Customer( val vorname: String, val nachname: String, val strasse: String, val geburtstag : String?, val hausnummer : Int, val hausnummerZusatz : String, val plz: String, val ort: String, val anrede: String, val firmenName : String?, val branche: String?, val handelsregisterEintrag : String?, val emailadresse : String?, val faxnummer: String?, val telefonnummer : String?, ) class Customer ( val vorname: String, val nachname : String, val strasse: String, val geburtstag : String?, val hausnummer : Int, val hausnummerZusatz : String, val plz: String, val ort: String, val anrede: String, val firmenName : String?, val branche: String?, val handelsregisterEintrag : String?, val emailadresse : String?, val faxnummer : String?, val telefonnummer : String?, val energieart : String, val haendlerId : String, )
13. Organisatorische Komplexität Wer macht denn eigentliche was?! Kategorie- Management Rechnungs- wesen Produkt- Management Marketing IT Fullfillment
14. 14 Kategorie- Managemen t Rechnungs- wesen Produkt- Managemen t Marketing IT Fullfillmen t UI Backend Master Data Payment Persistence Dimensionen der Komplexität Dimensionen der Komplexität
15. Core Domain Die Kernkompetenz der Unternehmung z.B. in einer Werkstatt die Planung der Reparaturen Supporting Domain Unterstützt die Core Domain, hat aber weniger Priorität. z.B. im eCom Bereich die Auswertung von Bestellungen Generic Domain kann gut durch gekaufte Software umgesetzt werden. z.B. Buchhaltung, Projektplanung Domain Driven Design Die Domain und Subdomains Domain Driven Design
16. Die Subdomain als “Problemraum” Der Bounded Context als “Lösungsraum” Umfasst nur die zur Lösung notwendigen Teile der Subdomain. Ideal: Pro Subdomain ein Bounded Context Optimal ein Team pro Bounded Context → Conway winkt um die Ecke Bounded Context Bounded Context
17. Ein Bounded Context ist ein logisch abgeschlossener Bereich. Fachlich, wie technisch. Ein Team allein kümmert sich um den Bounded Context. Kommunikation zwischen Bounded Context passiert über Domain Events oder Commands Dem Team stehen entsprechende Domainexperten zur Verfügung um gemeinsam die Subdomain zu erfassen. Nie in Stein gemeißelt! Auch ein Bounded Context kann sich ändern Bounded Context Bounded Context
18. Ubiquitous language “customer”: { “name”: “Max”, “surname”: “Mustermann”, “email”: “m.muster@inter.net”, “address”: “Fakestreet 123” } “newsfeed Target”: { “name”: “Max”, “surname”: “Mustermann”, “emailAddress”: m.muster@inter.net” } “customer”: { “firstname”: “Max”, “lastname”: “Mustermann”, “deliveryAddress”: “Fakestreet 123” } Search Shopping Cart Delivery Ubiquitous language
19. Eine gemeinsame Sicht auf die Domain Ubiquitous language Bounded Contexts self contained systems Building Blocks User Journey Maps Reverse Conway Manoeuvre Conway’s Law Die Context Map
20. Self contained systems (SCS) Jedes SCS bildet einen Bounded Context ab
21. Aufbau einer Context Map Produkt- Manageme nt Fullfillme nt Kategorie- Manageme nt Marketing Rechnungs- wesen Fullfillment Marketing Kategorie- Management Produkt- Management Rechnungs - wesen Domain ↔ Organisation Domain ↔ IT-Systeme IT-Systeme ↔ Organisation IT-Systeme <-> Organisation <-> IT-Systeme Optimum
22. • Partnership Zwei Teams mit zwei Bounded Context arbeiten an einem gemeinsamen Ziel. Enge Zusammenarbeit, kurze Kommunikation. • Customer Supplier Losere Kopplung als Partnership. Der “Supplier” Ist der Upstream, der Customer der Downstream. Beide Besprechen den Austausch, der Upstream bestimmt aber schlussendlich, was geschieht. • Shared Kernel Beide Contexte, bzw. Teams teilen sich einen Teil des Modells. Z.B. als Library etc. Enge Zusammenarbeit, Gefahr der “Ausfransung” des Modells. • Conformist Wie Customer Supplier. Der Downstream Host hat aber keine Entscheidungsmöglichkeit auf den Upstreamhost und muss mit dem Modell leben. Z.B. als Anbindung an eine “fremde” API. U D U D Strategic Design Pattern
23. • Anticorruption Layer Eine sehr defensive Verbindung, bei dem der Downstream das Upstream Modell und damit die ubiquitous language in das eigene Modell umwandeln und nicht direkt nutzt. Gut zur Integration “fremder” APIs. • Open Host Service Der Bounded Context bietet eine öffentliche, gut dokumentierte API an jeden “interessierten” Context an. Kann als “wohlwollender” Gegenpart zum Conformist-Pattern gesehen werden. • Published Language Ähnlich zum Open Host Service. Das Austauschformat, hier Language, wird als Schema (Json, XML), etc. dokumentiert hinterlegt. Basis für z.B. Contract Driven Testing D A C L O H S P L Strategic Design Pattern
24. • Separate Ways Wird eine Funktionalität benötigt, die entweder unvollständig implementiert ist oder aber der Integrationsaufwand den Nutzen nicht rechtfertigt, macht es ggf. Sinn die Funktionalität des anderen Context nachzubauen. • Big Ball of Mud Kein Design, aber oftmals die Realität. Verschiedene logische Contexte wurden ineinander verschachtelt und ohne eine passende Strategie verwebt und genutzt. Strategic Design Pattern
25. class Customer( val vorname: String, val nachname: String, val strasse: String, val geburtstag: String?, val hausnummer: Int, val hausnummerZusatz: String, val plz: String, val ort: String ) class Customer( val vorname: String, val nachname: String, val strasse: String, val geburtstag: String?, val hausnummer: Int, val hausnummerZusatz: String, val plz: String, val ort: String, val anrede: String, val firmenName: String?, val branche: String?, val handelsregisterEintrag: String?, val emailadresse: String?, val faxnummer: String?, val telefonnummer: String?, ) customer customer Gewachsene Strukturen trennen
26. Kommunikation zwischen Bounded Contexts / SCS Events sind passiv. “Hier ist etwas passiert. Du kannst es behandeln” Commands sind aktiv. “Ich möchte, dass du etwas tust!” Nicht verwechseln mit synchroner und asynchroner Kommunikation! Event: “Customer updated” Command: “Update customer” Domain Events / Commands
27. Identifizierung von Bounded Context und Subdomains Ein einzelner Context wird herausgelöst Identifizierung der Relationen Anbindung mit einem Anti Corruption Layer Keine “Kontamination” des Altsystems Fachblöcke herauslösen
28. technische Komplexität Komplexitätsreduktion fachliche Komplexität organisatorische Komplexität
29. technische Komplexität Komplexitätsreduktion Fachliche Komplexität minimieren
30. Komplexitätsreduktion
31. Fazit Systemsanierungen • sind nicht einfach • kosten eine Menge Geld, Ressourcen und Zeit • brauchen viel Geduld • Müssen eingepreist werden! DDD bietet Werkzeuge und Vorgehen zur Analyse einer Systemlandschaft • Bounded Context • Ubiquitous Language • Strategic Design • uvm. Aber • DDD ist nur ein Werkzeug im Werkzeugkasten • Das Herauslösung von Codeteilen ist nicht trivial! • Es sollte nie was in Stein gemeißelt sein!
32. Christian Schmidt IT Consultant / Software Architect Qvest Digital AG Am Dickobskreuz 10 53121 Bonn, Deutschland c.schmidt@qvest-digital.com christian-schmidt-it darktoast social/@DarkToast darktoast/systemmigration-mit-domain-driven-design Vielen Dank