SIGS DATACOM Fachinformationen für IT-Professionals

SOFTWARE MEETS BUSINESS:
The Conference for Software Architecture
Munich, 03 - 07 February 2020

Sessionsdetails

Talk: Di 5.1
Date: Tue, 04.02.2020
Time: 09:00 - 10:30
cart

Praktisches DDD Top-Down angewendet – Strategic Designs für Bounded Contexts

Time: 09:00 - 10:30
Talk: Di 5.1

 

15 Jahre nach der Veröffentlichung von Eric Evans Werk „Domain-Driven Design“ (DDD) ist die Methode in aller Munde. Ich berichte nun den begangenen Weg der DATEV eG vom Lernen und Lehren der DDD-Konzepte bis hin zur praktischen Nutzung der Strategic Designs und deren Visualisierung mittels Context Maps im täglichen Entwicklungsalltag. Ich zeige dabei die gehobenen Mehrwerte auf, wie wir unseren agilen Planungs- und Entwicklungsprozess als auch die Arbeit unserer Architekten veränderten und neugestalteten – der geschaffene Kompass „Into the Unkown“.

Zielpublikum: Architekten, Entscheider, Product Owner, Projektleiter
Voraussetzungen: Grundkenntnisse zu Domain-driven Design, Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Um in adäquater Geschwindigkeit flexibel und agil am Markt agieren zu können, ist es mehr denn je essenziell, alle laufenden und geplanten Entwicklungsvorhaben an klaren, unternehmensweiten Strategievorgaben ausrichten zu können. DATEV führte zu diesem Zweck ein unternehmensweites, systemisch ausgerichtetes Enterprise Architecture Management (EAM) ein. Parallel dazu wirkte mehr und mehr die Domain-driven Design (DDD)-Praktik im Hause. Die starke fachliche Orientierung des DDD sorgt für einen engen Schulterschluss mit unserem EAM und verbindet die Geschäftsstrategie und Geschäftsfähigkeiten mit der technischen Umsetzung.
In diesem Vortrag berichte ich von unserem Weg zur Anwendung des DDD. So führe ich in Kürze unsere angebotenen DDD-Fortbildungen ein, um DDD im Haus bekannt zu machen und zu etablieren. Nachdem ein solides Wissensfundament geschaffen wurde, etablierten wir die Beschreibung der Makro-Architektur mittels Context Maps. So dient uns diese Visualisierung der Systeme zum Abbilden auf die geforderten und im EAM-System erfassten Geschäftsfähigkeiten. Zusätzlich unterstützt uns dieses Vorgehen beim richtigen Schneiden von Microservices bzw. Self-contained Systems.
Wie sind die Abhängigkeiten und die nötigen Informationen, die miteinander konkretisiert und abgestimmt werden müssen? Wir diskutieren mittels der Context Maps, wie mehrere Teams anschließend soweit es geht autonom und autark wirken. Somit haben unsere Architekten ein probates Werkzeug erhalten, neue Anforderungen auf das System abzubilden und entsprechend die Wirkung darauf besser abschätzen zu können. Anhand der Context Maps kann ein zielgerichtetes Beheimaten von Erweiterungen bewerkstelligt werden.
Zusätzlich dienen die Context Maps unseren Product Ownern (POs) der Koordination und Priorisierung ihrer Backlogs. Die Abhängigkeiten zu anderen Teams sind darin leicht ablesbar und die POs können ihre Planungen einfacher aufeinander abstimmen.
Seit 1/2 Jahr setzen wir daher die Visualisierung als vorgeschriebenes Kommunikationsmittel in unserem Produktportfoliomanagement ein und gestalten damit Erweiterungen sowohl von bestehenden als auch neuen Anwendungen.