28 Jan Domain Driven Design im Einsatz
Einleitung
Dieser Beitrag führt kurz in das Konzept des Domain Driven Design ein und erläutertes mit einem Praxisbeispiel.
Domain Driven Design (DDD) ist ein Konzept für die Modellierung von Software (Siehe DDD in der Wikipedia). Es wird in verteilten Systemen eingesetzt, um die einzelnen Bereiche unabhängiger zu gestalten. Den mittlerweile bekannteste Anwendungsfall stellen Microservices dar, ein weiterer findet sich in ERP Systemen.
Neben dem konzeptuellen Ansatz ist eine Team-übergreifende fachliche Sprache wichtig (sog. 'Ubiquitäre Sprache'). Alle Beteilige in einem Projekt müssen für eine fachliche Gegebenheit den selben Begriff verwenden. Z.B. müssen Product Owner, Scrum Master und Programmierer den Rollenamen 'Verkäufer' verwenden (und nicht mal Verkäufer, mal Vertriebler oder auch mal Salesman).
In der Praxis heißt das, dass Team-übergreifend Dokumente, Objekte, Services, Testfälle usw. das gleiche Wording verwendet müssen. Findet das nicht statt, werden Bestandteile der Software in ähnlicher Weise mehrfach implementiert – das System erodiert.
Domain Driven Design in ERP Systemen
Das klassische ERP System beginnt als Monolith. Nach dem Erreichen einer gewissen Größe wird es oft in Module aufgeteilt (CRM, WaWi, HR, SCM… - die man oft auch getrennt lizensieren kann). Diese Module verwenden Libraries und Funktionen, die zu dem jeweiligen Modul gehören. Aber es ist z.B. dem CRM-Modul erlaubt, z.B. direkt in dem SCM-Modul zu lesen. Meist ist auch Schreiben Modul-übergreifend erlaubt.
Den nächsten Schritt der in der Evolution stellt die (bewusste oder unbewusste) Einführung des DDD dar. Damit werden die Module zu Domains und die Wartungsaufwände reduziert. In einer Domain dürfen nur noch die dazugehörigen Programme lesen und schreiben. In meinem Beispiel mit CRM und SCM (siehe Schaubild weiter unten) sieht die Aufteilung z.B. so aus:
- Das CRM enthält die Kundendaten, Lieferantendaten, Telefonate, Termine etc.
- Das SCM enthält die Planungen (Logistik) für Lieferanten und Endkunden
- Das CRM verwendet auch SCM Daten
- Konsolidierte Daten aus dem SCM werden über Business Entities abgefragt
z.B. für Anzeige Kunde und Anzahl Lieferungen in den letzten Jahren - Statusdaten von Lieferungen werden in das CRM repliziert
z.B. für Auswertungen der top/flop Lieferanten
- Konsolidierte Daten aus dem SCM werden über Business Entities abgefragt
- Das SCM verwendet auch CRM Daten:
- Der Vendor Follow-Up verwendet Detaildaten aus SCM Business Entities
- SCM Jahresauswertungen verwenden replizierte CRM Daten
Domain Konzept in der Entwicklung
Das Domain Konzept unseres Low-Code Development Systems OF-1 findet bei der Erstellung von ERP Software Anwendung. Als Beispiel aus der Praxis mag unser Tickettracker dienen, der als browserbasierte Software auch von den Kunden eingesetzt wird. Er liest seine Benutzerdaten und -berechtigungen aus dem zentralen hauseigenen ERP. Die Informationen über die Fertigstellung von Tickets - und dem Zeitaufwand dafür - werden vom ERP für die Abrechnungen per Call vom Tickettracker abgeholt.
Ergänzende Punkte:
- Datenreplikation ist nur für Massendaten sinnvoll, das ist Fall für Fall abzuwägen
- Domains sollten sich aus Performance Gründen ein gemeinsamen Netzwerk teilen
- Domains können sich eine Datenbank teilen (üblich bei ERP Systemen, unüblich bei Microservices)
- Microservices haben oft auch Failover-Fähigkeiten, z.B. per Event-Sourcing
Gerne beraten wir Sie über den Einsatz von Domain Driven Design in Ihrem Projekt – unabhängig von der verwendeten Technologie.
Klaus Erichsen
Blog Eintrag "Domain Driven Design – DDD – im Einsatz"
Hamburg, 27 Januar 2020
Über die IAP GmbH:
Die IAP GmbH bietet seit 1992 professionelle Softwareentwicklung und technische Beratung an. Gerne pflegen wir auch Bestandssoftware (Legacy System Maintenance) fast jeglicher Couleur.
Kontakt: Klaus Erichsen, +49 – 176 208 600 62,