Domain Storytelling ist eine Methode für Collaborative Modeling. Sie bringt Fachexpert:innen und Entwickler:innen zusammen und hilft ihnen, die Domäne zu verstehen, Grenzen zwischen Microservices zu finden und über Anforderungen zu sprechen.

Domain Storytelling heißt, dass wir unsere Anwender:innen Geschichten von ihren Aufgaben erzählen lassen. Beim Zuhören zeichnen wir die Geschichten mit einer grafischen Sprache auf.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager:innen, Entscheider:innen, POs
Voraussetzungen: Lust auf ein neues Werkzeug
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Domain Storytelling ist eine Methode für Collaborative Modeling. Sie bringt Fachexpert:innen und Entwickler:innen zusammen und hilft ihnen, die Domäne zu verstehen, Grenzen zwischen Microservices zu finden und über Anforderungen zu sprechen.
Domain Storytelling heißt, dass wir unsere Anwender:innen Geschichten von ihren Aufgaben erzählen lassen. Beim Zuhören zeichnen wir die Geschichten mit einer grafischen Sprache auf.
Unsere Fachexpert:innen können direkt sehen, ob wir sie richtig verstehen und was wir noch falsch verstehen. Nach nur wenigen Stories verstehen wir die Sprache unserer Anwender:innen und können ein Domänenmodell daraus bauen und implementieren.

Software ist in nahezu allen Bereichen unseres Lebens unverzichtbar. Neben der Forderung, dass die Software fachlich tut, was sie soll, ist wichtig, dass unsere Softwaresysteme langfristig wartbar und erweiterbar bleiben.

In diesem Talk bekommen Zuhörende Anleitungen, Erkenntnisse, Hinweise und viele Beispiele aus der Praxis, wie die Techniken aus Domain-Driven Design für Softwaresysteme verwendet werden können, die über Jahre gewachsen und möglicherweise ohne Architekturverständnis entwickelt wurden.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager:innen, Entscheider:innen
Voraussetzungen: Projekterfahrung, Architekturerfahrung
Schwierigkeitsgrad: Fortgeschritten

Im Zuge unseres angestrebten Portfoliowandels hin zu Cloud-native Microservice Architekturen müssen auch wir Berge versetzen. DDD lässt sich in Bestandanwendungen leider nicht direkt in seinem vollen Umfang anwenden. Dennoch helfen die DDD-Methoden und Tools, um die Entwicklungen zielgerichteter und nachhaltiger zu gestalten. Dreh- und Angelpunkt unserer Modernisierung ist das kontinuierliche Optimieren der Bounded Contexts, um motivierte und leistungsfähige Teams zu erreichen. Ich berichte hier von unserem steinigen Weg und unseren Ergebnissen.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager:innen, Entscheider:innen
Voraussetzungen: Grundverständnis DDD
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Um am Markt mit steigender Digitalisierung und zunehmender Automatisierung erfolgreich bestehen zu können, müssen Unternehmen flexibler und agiler werden. Es ist mehr denn je essenziell, alle laufenden und geplanten Entwicklungsvorhaben effizient und in adäquater Geschwindigkeit abzuschließen.

In diesem Vortrag steigen wir vertiefend in den projektübergreifenden Domain-driven-Design-Ansatz ein. Wir bei DATEV verfügen über eine heterogene Infrastruktur und Produktlandschaft. Die Teamgrenzen und damit die Verantwortungsbereiche entsprechen nicht dem DDD-Idealbild. Die existierende technologische Heterogenität kann nicht auf einen Schlag abgelöst und mittels Microservices realisiert werden. Gerade klassische Infrastrukturen erfordern spezielle Fertigkeiten der Entwicklerteams, die nicht nur auf die Programmiersprache zurückzuführen sind. Folglich ist das Aufarbeiten und Anwenden der DDD-Werkzeuge nicht ganz so geradlinig wie bei „green field“-Projekten. Dennoch müssen auch hier neue, innovative Erweiterungen beispielsweise aus dem Umfeld von Künstlicher Intelligenz oder Big Data eingebracht werden.

Das Gute vorweg: Es lässt sich trotzdem die Architektur (sowohl die der Software als auch der Organisation) sowie die bisher umgesetzte Fachlichkeit im Lichte von DDD beleuchten und abbilden. Viele der geläufigen Methoden wie Event Storming, Domain Storytelling oder Boris Exercise konnten wir gewinnbringend nutzen. Die ermittelten Erkenntnisse lassen sich dazu verwenden, um die weiteren Entwicklungen und Modernisierungen zu platzieren und einzuplanen. Unser Dreh- und Angelpunkt der Modernisierungsvorhaben ist unser Ansatz der weitergefassten Definition des Bounded Contexts. Diese Bounded Contexts dienen uns zur gemeinsamen Diskussion der Abhängigkeiten der Anwendungsteile und natürlich der entwickelnden Teams. Wie sind die Abhängigkeiten und die nötigen Informationen, die miteinander konkretisiert und abgestimmt werden müssen. Wir diskutieren mittels Context Maps, wie die betroffenen Teams anschließend zusammenwirken können. Dabei versuchen wir, durch schrittweise Umorganisation und Verschieben von Fachlichkeit die Autonomie der Teams zu verbessern. Ein kontinuierliches Optimieren der Bounded Contexts ist dabei der eigentliche Weg zu schlagkräftigen, motivierten und leistungsfähigen Teams. Einige dieser Wege, die den umfangreichen und komplexen Domänen in der Legacy-Welt gerecht werden möchten, werde ich aufzeigen und erklären.

In an ever increasing need of remote work, we still need to envision new business models, explore our business processes and design our software systems. While nothing can replace the in person collaboration of an EventStorming, remote tools bring their own exciting upsides. During the lock down of the COVID-19 pandemic the DDD community experimented and distilled a collection of remote modelling methods. Let us together dive into some interesting trade-offs and find amazing new tools that carry us into the future.

Target Audience: Senior developers, Software Architects, Facilitators, Consultants, C*Os
Prerequisites: A basic understanding of why we model and how communication influences software would be good
Level: Advanced

Extended Abstract:
We will explore remote EventStorming, remote Context Mapping with Bounded Context Canvas, architecture design and documentation emerging from and integrated into the model and many more.