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

SOLID principles are well-known for designing object-oriented systems. But what if you are developing microservices? IDEALS, is yet another silly mnemonic acronym and are the core principles for microservice design. The acronym stands for: Interface segregation, Deployability, Event-driven, Availability over consistency, Low Coupling, and Single responsibility. We will relate these IDEALS to techniques, tools, technologies, and domain modeling principles we use today to develop modern service-based distributed systems (microservices).

Target Audience: English, Developers, Architects, QAs, Testers, Product Owners, Managers
Prerequisites: Basic Understanding of architecture and microservices and familiarity with domain modeling
Level: Advanced

Extended Abstract:

It's been seven years since we've started creating microservices. Practice has shown what design principles give you a sound foundation for a successful microservice architecture. Join us in this session to find out what they are, and how to realize them. For OO systems, Robert Martin compiled the five SOLID principles. For designing microservice-based solutions, we propose developers follow the "IDEALS":  

(I) Interface segregation tells us that different types of clients (e.g., mobile apps, web apps, CLI programs) should be able to interact with services through the contract that best suits their needs. 

(D) Deployability (is on you) acknowledges that in the microservice era, which is also the DevOps era, there are critical design decisions and technology choices developers need to make regarding packaging, deploying and running microservices. 

(E) Event-driven suggests that whenever possible we should model our services to be activated by an asynchronous message or event instead of a synchronous call. 

(A) Availability over consistency reminds us that more often end users value the availability of the system over strong data consistency, and they're okay with eventual consistency. 

(L) Loose-coupling remains an important design concern in the case of microservices, with respect to afferent (incoming) and efferent (outgoing) coupling. 

(S) Single responsibility is the idea that enables modeling microservices that are not too large or too slim because they contain the right amount of cohesive functionality. 

We will relate these IDEALS to techniques, tools, technologies and domain modeling principles we use today to develop modern service-based distributed systems (microservices).

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.

Languages that raise the level of abstraction closer to the problem domain help improve quality and productivity. This can be best achieved when the language is directly based on the problem domain, not implementation concepts or existing languages. We describe how to create domain-specific languages in tight collaboration with domain expert users: as soon as a language concept is defined it can be immediately applied by users. We demonstrate this with examples from various fields, such as automotive, home electronics and automation systems.

Target Audience: Developers, subject matter/domain experts, managers
Prerequisites: experiences on applying some modeling language
Level: Advanced

Extended Abstract:
This talk is based on industry experiences on applying domain terminology directly in a modeling language (in its grammar). This way domain experts can apply familiar terminology, and map the specifications directly to code, to other more technical models, or the same set of models are shared by both domain experts and developers. The talk starts with a practical example how domain experts from different fields can collaboratively edit the same specifications each having own background (industry process, software, hardware, communication). Next the talk describes guidelines how such languages can be created: how domain terminology is defined into a language and how such language can be applied. These guidelines are demonstrated with examples from practice, such as how functional safety engineers can collaborate using ISO26262 (functional safety standard) terminology and related them to the technical system development; and how UX and UI persons can define user interfaces and their behavior in a manner allowing developers to join and work with the same models. The talk is concluded with guidelines and hints backed by industry cases from companies like Panasonic and Elektrobit.

Ein halbes Jahrhundert der Software-Entwicklung ist von einem überraschenden Phänomen geprägt: Wir, die Entwickler:innen + Architekt:innen, haben nicht nur immer wieder neue Technologien und Architekturansätze geschaffen, sondern auch Methoden entwickelt, die über die reine Programmierung hinausgehen. Projektleiter, Anwender, Betrieb und Tester haben von unseren Innovationen profitiert. Dieser Vortrag berichtet über die erstaunlichen Beiträge, die unsere Disziplin konzipiert und entwickelt hat, und wagt einen Blick in die Zukunft unserer Disziplin.

Zielpublikum: Alle
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Nach diesem Vortrag werden die Teilnehmenden voller Motivation ihre Reise durch die OOP antreten.

Neben dem Blick in die Vergangenheit wird die Zukunft unserer Disziplin den Schwerpunkt dieses Vortrags bilden.

Unter „Resilienz“ versteht man die Fähigkeit von Systemen, auch unter massiven Störungen von außen ihre Funktionsfähigkeit zu erhalten. Die Coronakrise mit ihren massiven Einschnitten und Opfern hat uns vor Augen geführt, dass Resilienz von Unternehmen entscheidend sein kann für das weitere Überleben. In diesem Vortrag betrachten wir Situationen, in denen Resilienz von besonderer Bedeutung ist, und leiten daraus ab, welche Voraussetzungen Unternehmen erfüllen müssen, um Resilienz zu zeigen. Spoiler: Auch Agilität spielt dabei eine Rolle ...

Zielpublikum: Manager:innen, Entscheider:innen, Organisations-Entwickler:innen, Coaches
Voraussetzungen: Verständnis über Unternehmenssteuerung und Agilität
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Roter Faden dieses Talks ist eine Analogie zwischen der Situation, in der sich Unternehmen während der Coronakrise befanden und noch immer befinden, und den (frei interpretierten) Phasen der Behandlung lebensbedrohlicher medizinischer Notfälle, für die sich in den letzten 50 Jahren weltweite Standards etabliert haben (nein, es wird keine Schockfotos geben. Mir geht es um Taktik und Strategie, nicht um Sensationslust).

Für jede der Phasen (unmittelbare Existenzsicherung, Ursachenfindung, Aufbau von Handlungsoptionen, Ausprobieren der Optionen, Einrichten auf die neue Normalität) wird analysiert, welche Eigenschaften und Praktiken Unternehmen dabei unterstützen oder behindern und wie man sie fördern kann. Dass dabei viele Ähnlichkeiten mit agilen Ansätzen aufscheinen, ist nicht überraschend, wichtig sind aber auch die Bereiche, in denen Agilität alleine nicht ausreicht.

Was hat das mit Tintenfischen zu tun? Diese kommen aus einer Analogie der "Supporting Agile Adoption"-Arbeitsgruppe der Agile Alliance, in der Oktopusse als Beispiel für einen völlig anders organisierten Organismus dienen, der dezentral mit neun Gehirnen kognitive Leistungen erbringt, die sich mit intelligenten Säugetieren messen lassen können. Es zeigt sich, dass die Fähigkeit von Organisationen, Entscheidungen verteilt fällen zu können, ihre Resilienz wesentlich verbessern kann.