Systemsanierung mit DDD

Transcript

1. ENJOY DIGITAL CHANGE SYSTEMSANIERUNG MIT DDD EINE GESCHICHTE VON KOMPLEXITÄT
2. WHO WE ARE Wir beraten unsere Kunden bei ihren digitalen Herausforderungen und realisieren gemeinsam die Zukunft. Wir unterstützen unsere Kunden mit innovativen Vorgehensmodellen und den aktuellsten Technologien. MISSION 26 Jahre Erfahrung 300+ IT-Expert*innen 30 Digitalisierungs- expert*innen 13 Partner 27 Entwicklungs- projekte parallel BONN BERLIN KÖLN BUKAREST 5 Standorte +
3. CHRISTIAN SCHMIDT (36) • Aus Morsbach -> hinter den sieben Bergen • Seit über 11 Jahren bei der tarent • Java, Kotlin, Scala, Go, Docker, Kafka, Cloud & alles was Bleeding Edge ist • @chris__schmidt • https://github.com/darktoast • https://gitlab.com/christian_schmidt
4. EINES MITTWOCH MORGENS…
5. EINES MITTWOCH MORGENS… Schadensaufnahme Plausibilitätsprüfung Abwicklung
6. EINES MITTWOCH MORGENS… ä
7. EINES MITTWOCH MORGENS… io.ktor.server.plugins.BadRequestException: Illegal json parameter found at io.ktor.server.plugins.contentnegotiation.RequestConverterKt$convertRequestBody$1$1.invokeSuspend(RequestConverter.kt:45) at io.ktor.server.plugins.contentnegotiation.RequestConverterKt$convertRequestBody$1$1.invoke(RequestConverter.kt) at io.ktor.server.plugins.contentnegotiation.RequestConverterKt$convertRequestBody$1$1.invoke(RequestConverter.kt) at io.ktor.server.application.OnCallReceiveContext.transformBody(KtorCallContexts.kt:65) at io.ktor.server.plugins.contentnegotiation.RequestConverterKt$convertRequestBody$1.invokeSuspend(RequestConverter.kt:22) at io.ktor.server.plugins.contentnegotiation.RequestConverterKt$convertRequestBody$1.invoke(RequestConverter.kt) at io.ktor.server.plugins.contentnegotiation.RequestConverterKt$convertRequestBody$1.invoke(RequestConverter.kt) at io.ktor.server.application.PluginBuilder$onCallReceive$3.invokeSuspend(PluginBuilder.kt:165) at io.ktor.server.application.PluginBuilder$onCallReceive$3.invoke(PluginBuilder.kt) at io.ktor.server.application.PluginBuilder$onCallReceive$3.invoke(PluginBuilder.kt) at io.ktor.server.application.PluginBuilder$onCallReceive$2.invokeSuspend(PluginBuilder.kt:109) at io.ktor.server.application.PluginBuilder$onCallReceive$2.invoke(PluginBuilder.kt) at io.ktor.server.application.PluginBuilder$onCallReceive$2.invoke(PluginBuilder.kt) at io.ktor.server.application.PluginBuilder$onDefaultPhase$1.invokeSuspend(PluginBuilder.kt:217) at io.ktor.server.application.PluginBuilder$onDefaultPhase$1.invoke(PluginBuilder.kt) at io.ktor.server.application.PluginBuilder$onDefaultPhase$1.invoke(PluginBuilder.kt) at io.ktor.server.application.PluginBuilder$onDefaultPhaseWithMessage$1$1$1.invokeSuspend(PluginBuilder.kt:200) at io.ktor.server.application.PluginBuilder$onDefaultPhaseWithMessage$1$1$1.invoke(PluginBuilder.kt) at io.ktor.server.application.PluginBuilder$onDefaultPhaseWithMessage$1$1$1.invoke(PluginBuilder.kt) at io.ktor.util.debug.ContextUtilsKt.addToContextInDebugMode(ContextUtils.kt:30) at io.ktor.server.application.PluginBuilder$onDefaultPhaseWithMessage$1$1.invokeSuspend(PluginBuilder.kt:196) at io.ktor.server.application.PluginBuilder$onDefaultPhaseWithMessage$1$1.invoke(PluginBuilder.kt) at io.ktor.server.application.PluginBuilder$onDefaultPhaseWithMessage$1$1.invoke(PluginBuilder.kt) at io.ktor.util.pipeline.DebugPipelineContext.proceedLoop(DebugPipelineContext.kt:80) at io.ktor.util.pipeline.DebugPipelineContext.proceed(DebugPipelineContext.kt:57) at io.ktor.util.pipeline.DebugPipelineContext.execute$ktor_utils(DebugPipelineContext.kt:63) at io.ktor.util.pipeline.Pipeline.execute(Pipeline.kt:77) at io.ktor.server.request.ApplicationReceiveFunctionsKt.receive(ApplicationReceiveFunctions.kt:88) at de.tarent.crud.controller.GroupsKt$groupPage$1$3.invokeSuspend(groups.kt:97) at de.tarent.crud.controller.GroupsKt$groupPage$1$3.invoke(groups.kt)
8. EINE STUNDE SPÄTER… master data process engine UI Statistics Billing Schaue ich mir mal an
9. NACH DEM MITTAG… master data process engine UI Statistics Billing • Wann war das genau? Also die Uhrzeit. Möglichst mit Sekunden. • In welchem Prozessschritt? • Trat das schon mal auf? • Welche Abteilung war das?
10. ZWEI TAGE SPÄTER… master data process engine UI Statistics Billing Leute! Das ist doch MasterData! Ich schicke das Ticket mal weiter.
11. WAS IST PASSIERT? Schadensaufnahme Plausibilitätsprüfung Abwicklung Statistik UI Masterdata Processengine Billing Statistics Systeme Fachliche Blöcke
12. KONTRÄRE SICH AUF DAS SYSTEM Schadensaufnahme Plausibilitätsprüfung Abwicklung Statistik UI Masterdata Processengine Billing Statistics Systeme Fachliche Blöcke
13. KONTRÄRE SICH AUF DAS SYSTEM Schadensaufnahme Plausibilitätsprüfung Abwicklung Statistik UI Masterdata Processengine Billing Statistics Systeme Fachliche Blöcke
14. KONTRÄRE SICH AUF DAS SYSTEM Schadensaufnahme Plausibilitätsprüfung Abwicklung Statistik UI Masterdata Processengine Billing Statistics Systeme Fachliche Blöcke
15. SYSTEMLANDSCHAFT - THEORIE master data process engine UI Statistics Billing
16. SYSTEMLANDSCHAFT - PRAXIS process engine UI Statis tics Billing master data
17. SYSTEMLANDSCHAFT - PRAXIS process engine UI Statis tics SAP master data DB2
18. TECHNISCHE KOMPLEXITÄT • Große, umfassende Modelle • Technische Orientierung • Verwobene Fachlichkeiten • geteilte Codebase • Unklare Zuständigkeiten • in die Jahre gekommen
19. MEIN AKTUELLES PROJEKT IBM - AS400 / i Series Mainframe • voll integrierte Systemlösung • IBM-POWER 9 CPUs • OS/400 bzw. i5/OS • Fest integrierte OS/2 for i Datenbank • Fest integriertes IAM per IBM Directory Server for IBM i (LDAP) • Entwicklung in RPG • Greenscreen Applikation
20. technische Komplexität TECHNISCHE & FACHLICHE KOMPLEXITÄT Fachliche Komplexität • Fachliche Komplexität ◦ Prozesse ◦ Modelle ◦ Personas ◦ Dokumentation • technische Komplexität ◦ Transaktionen ◦ Security ◦ asynchrone Kommunikation ◦ Serialisierung ◦ etc…
21. technische Komplexität TECHNISCHE & FACHLICHE KOMPLEXITÄT Fachliche Komplexität • Fachliche Komplexität ◦ Prozesse ◦ Modelle ◦ Personas ◦ Dokumentation • technische Komplexität ◦ Transaktionen ◦ Security ◦ asynchrone Kommunikation ◦ Serialisierung ◦ etc…
22. technische Komplexität TECHNISCHE & FACHLICHE KOMPLEXITÄT Fachliche Komplexit ät • Fachliche Komplexität ◦ Prozesse ◦ Modelle ◦ Personas ◦ Dokumentation • technische Komplexität ◦ Transaktionen ◦ Security ◦ asynchrone Kommunikation ◦ Serialisierung ◦ etc…
23. ZWISCHENFAZIT Systeme Fachliche Blöcke • konträre Architektur • zerfaserte Codebase • hohe technische Komplexität
24. CONWAYS LAW “Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.” - Melvin Edward Conway
25. DOMAIN / SUBDOMAINS • Die Domain wird in Subdomains aufgeteilt ◦ 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
26. BOUNDED CONTEXT • Bounded Context ◦ Die Subdomain als “Problemraum” ◦ Der Bounded Context als “Lösungsraum” - umfasst nie die gesamte Subdomain! ◦ Ideal: Pro Subdomain ein Bounded Context • Optimal ein Team pro Bounded Context
27. BOUNDED CONTEXT • 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
28. UBIQUITOUS LANGUAGE “customer”: { “name”: “Max”, “surname”: “Mustermann”, “email”: “m.muster@inter.net”, “address”: “Fakestreet 123” } “newsfeedTarget”: { “name”: “Max”, “surname”: “Mustermann”, “emailAddress”: m.muster@inter.net” } “customer”: { “firstname”: “Max”, “lastname”: “Mustermann”, “deliveryAddress”: “Fakestreet 123” } Customer Data Newsfeeds Delivery
29. CONTEXT MAP / STRATEGIC DESIGN Statistics Plausibilitäts- prüfung Schadensaufn ahme Abwicklung
30. STRATEGIC DESIGN PATTERN • 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
31. STRATEGIC DESIGN PATTERN • 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
32. STRATEGIC DESIGN PATTERN • 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.
33. DOMAIN EVENTS / COMMANDS • Einzige Kommunikation zwischen Bounded Contexts durch Events oder Commands • 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”
34. SYSTEMSANIERUNG - STATUS QUO Statistics Plausibilitäts- prüfung Schadens aufnahme Abwicklung Process Engine Master Data UI Billing Statistics
35. ARCHITEKTUR • 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.
36. SYSTEMSANIERUNG Statistics Plausibilitäts- prüfung Schadens aufnahme Abwicklung Process Engine Master Data UI Billing Statistics Schadens- aufnahme
37. ARCHITEKTUR - SELF CONTAINED SYSTEMS Bounded Context ⇒ ➢ Conway's Law ➢ Self contained systems (SCS) ➢ 1 SCS → 1 Team 1 SCS → 1 - n µServices UI model Service UI model Service asynchron
38. ARCHITEKTUR - HERAUSLÖSEN A C L • Identifizierung von Bounded Context und Subdomains • Ein einzelner Context wird herausgelöst • Identifizierung der Relation • Eine Anbindung mindestens mit dem Anti-Corruption Layer. Das eigene Modell sollte nie mit dem “Modell” des BBoM “kontaminiert” werden.
39. SYSTEMSANIERUNG Statistics Plausibilitäts- prüfung Schadens aufnahme Abwicklung Master Data UI Billing Statistics Schadens- aufnahme Process Engine
40. SYSTEMSANIERUNG Statistics Plausibilitäts- prüfung Schadens aufnahme Abwicklung Master Data UI Billing Statistics Schadens- aufnahme Process Engine Masterdata
41. SYSTEMSANIERUNG Statistics Plausibilitäts- prüfung Schadens aufnahme Abwicklung Master Data UI SAP BI Schadens- aufnahme Process Engine Masterdata benötigt von allem Daten
42. SYSTEMSANIERUNG Statistics Plausibilitäts- prüfung Schadens aufnahme Abwicklung Master Data SAP BI Schadens- aufnahme Plausibilitäts- prüfung Masterdata benötigt von allem Daten
43. SYSTEMSANIERUNG Statistics Plausibilitäts- prüfung Schadens aufnahme Abwicklung Master Data SAP BI Schadens- aufnahme Plausibilitäts- prüfung Masterdata Domain events Customer Supplier Conformist benötigt von allem Daten Conformist konsumiert Events
44. ZUM THEMA MONOLITH Statistics Plausibilitäts- prüfung Schadens aufnahme Abwicklung Master Data SAP BI Schadens- aufnahme Plausibilitäts- prüfung Masterdata
45. FAZIT • DDD bietet Werkzeuge und Vorgehen zur Analyse einer Systemlandschaft ◦ Context Map ◦ Strategic Design Pattern ◦ Ubiquitous Language • Per Domain Events und Commands existieren Austauschtechniken ◦ Asynchron ◦ Synchron • Aber: ◦ DDD ist nur ein Werkzeug im Werkzeugkasten ◦ Das Herauslösung von Codeteilen ist nicht trivial! ◦ Ein Bounded Context sollte nie in Stein gemeißelt sein!
46. ENJOY DIGITAL CHANGE Bonn Am Dickobskreuz 10 53121 Bonn Berlin Kohlfurter Str. 41/43 10999 Berlin Köln Kennedy-Ufer 11 50679 Köln Christian Schmidt Senior Software Engineer IT Consultant c.schmidt@tarent.de @chris__schmidt darktoast christian-schmidt-9644a91b2 DANKE