Creating high-quality software is challenging due to a focus on solutions over understanding organizational context. Developers need to engage with stakeholders across contexts. However, stakeholder communication can lead to misunderstandings and conflicts, disrupting knowledge sharing. This often results in autocratic decisions by architects. Achieving sustainable and design decisions, it's more effective to employ visual techniques, improving collaboration with stakeholders.

This talk explores collaborative modeling, a technique for analyzing complex decisions with all stakeholders. Inclusive sessions and skills like observing, listening, neutrality, and empathy are key. The goal is for teams to understand stakeholder needs, guiding software architecture through collaborative design.

Target Audience: Technical leaders, decision makers, software engineers, architects
Prerequisites: None
Level: Advanced

In den letzten Jahren hat das Strategische Design aus DDD einen enormen Zuspruch gewonnen, was auf jeden Fall gut und wichtig ist. Aber das bedeutet nicht, dass wir das Taktische Design von DDD vernachlässigen sollten.

Für diesen Vortrag beginnen wir mit einer starren und fragilen Codebase, wie sie häufig im Laufe der Jahre entsteht. Wir führen Schritt für Schritt Refactorings durch, wobei wir den Supple Design Strategien (supple: englisch für “geschmeidig”) aus DDD sowie anderen bekannten Refactoring-Patterns folgen. Dabei führen wir Value Objects, Entities und weitere Elemente des Taktischen Designs nach und nach ein. Dies erlaubt es uns, die Codebase klar zu strukturieren, so dass Änderungen schnell und leicht möglich sind und das Arbeiten mit dem Code wieder Freude bereitet.

Konkret lernen die Teilnehmer, in welchen Schritten diese Strategien gut anwendbar sind. Die einzelnen Schritte sind einfach und klar verständlich. Sie fordern zum Nachdenken heraus und geben Einblicke, mit denen wir das Domänenmodell im Laufe des Refactorings signifikant verbessern.

Zielpublikum: Architekten, Entwickler
Voraussetzungen: Programmiererfahrung, Erfahrung mit größeren und älteren Codebasen hilfreich
Schwierigkeitsgrad: Advanced

Seit über sechzig Jahren bauen wir Software, die immer größer und komplexer wird. Inzwischen haben wir nicht nur Mainframe-Altsysteme, sondern auch die Systeme in objektorientierten Programmiersprachen sind in den letzten zwanzig Jahren so schnell und immer wieder unkontrolliert gewachsen, dass sie zu einem großen Knäuel geworden sind. All dieser Legacy-Code treibt die Entwicklungskosten in die Höhe und führt dazu, dass wir diese alten Softwaresysteme nicht mehr gerne anfassen. Ist das unvermeidbar? Oder gibt es auch gute Legacy?

In meinem Vortrag zeige ich Ihnen, welche Überlegungen ich mit meinen Kunden üblicherweise anstelle, um zu entscheiden, ob das Legacy-System durch Refactorings wieder auf den Pfad der Tugend gebracht werden kann oder ob wir es abreißen und neu bauen müssen.

Zielpublikum: Architekten, Entwickler, Projektleiter, Manager
Voraussetzungen: Erfahrung mit Softwareentwicklung
Schwierigkeitsgrad: Advanced

Bounded Contexts spielen bei Domain-driven-Design-Diskussionen eine zentrale Rolle. Sie gelten als eine vielversprechende Lösung zur Modularisierung von Systemen, sei es in Form von Deployment-Monolithen oder Microservices. Doch die Anwendung in der Praxis bringt Herausforderungen mit sich: Es ist oft schwierig, eine Domäne sinnvoll in Bounded Contexts aufzuteilen. Zudem ist das Konzept nicht einfach zu verstehen. Einerseits steht es für die Aufteilung eines Softwaresystems in Module, andererseits soll es helfen, verschiedene Fachsprachen innerhalb einer Domäne voneinander zu trennen. Darüber hinaus wird ein Bounded Context oft als ein Team betrachtet. Wie lässt sich all das miteinander in Einklang bringen, und wie kann man in der Praxis erfolgreich damit arbeiten? Dieser Vortrag erklärt, was Bounded Contexts sind, und beleuchtet dann diese Herausforderungen. So zeigt er, wie man Projekte mit DDD noch erfolgreicher gestalten kann.

Zielpublikum: An Softwarearchitektur oder Domain-driven Design Interessierte
Voraussetzungen: Grundlegendes Verständnis von DDD
Schwierigkeitsgrad: Advanced

Die Grundlage für gute Software ist eine gute Architektur. Eine zum System passende Architektur kann jedoch nicht im luftleeren Raum entstehen – um eine geeignete Architektur definieren zu können, muss man die Domäne und ihre Anforderungen verstehen. Moderne Architekturarbeit beginnt somit ein ganzes Stück vor der eigentlichen Architektur. Für diese Exploration der Domäne wurden im Rahmen von Domain-Driven Design (DDD) verschiedene kollaborative Modellierungstechniken entwickelt. Deren Ziel ist es, dass alle an einer Software beteiligten Personen die Domäne und ihre Anforderungen kennen und verstehen. Insbesondere soll eine gemeinsame Sprache entwickelt werden, um über Problemstellungen innerhalb der Domäne diskutieren zu können, die auch als Ubiquitous Language im Sinne von DDD verwendet werden kann.

Obwohl all diese Modellierungstechniken dieselben Ziele verfolgen, unterscheiden sie sich in ihrem Ansatz. Das beliebte Event Storming modelliert Wissen als Sequenz von Events. Beim Domain Storytelling werden die Interaktionen zwischen Personen und/oder Systemen modelliert und die Ergebnisse können zur Visualisierung von Szenarien verwendet werden. Weitere Methoden verwenden andere Elemente in der Modellierung oder versuchen, die Stärken anderer Methoden zu kombinieren. In diesem Vortrag möchten wir einige beliebte Modellierungstechniken kurz vorstellen und ihre Stärken hervorheben. Wir möchten einige Ratschläge geben, wie man auf Basis des Szenarios eine kollaborative Modellierungstechnik auswählt.

Zielpublikum: Architekten, Entwickler, Projektleiter
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Basic

Today we know very well how to start a new project on a greenfield and how to build a good architecture. But most of us work in projects that have been around for a long time and whose architecture (to put it mildly) is not quite so beautiful. “Monolith” and “Big Ball of Mud” are the unflattering labels put on such systems.

This talk will show how we can introduce (or bring back) structure. Every system is different here, so it’s important to first understand where you are. Then the right steps have to be taken. We present a catalog of refactorings to choose from and heuristics which are the right choices.

The catalog contains refactorings that help to cure: BBOM architecture, anemic domain models, and badly organized teams.

Target Audience: Developers and architects
Prerequisites: Programming experience
Level: Expert

Wir wissen heutzutage ziemlich gut, wie man ein neues Entwicklungsprojekt auf der grünen Wiese beginnen sollte und wie wir dabei Schritt für Schritt eine gute Softwarearchitektur aufbauen. Aber die meisten von uns arbeiten in Projekten, die schon lange laufen und deren Architektur nicht mehr ganz so wohlgeformt ist. „Monolith“ und „Big Ball of Mud“ sind die unschönen Bezeichnungen, die wir für diese Systeme haben.

In diesem Vortrag stelle ich Domain-Driven Transformation vor, eine Methode, die Henning Schwentner und ich in den letzten Jahren beim Verbessern von Altsystemen entwickelt haben. Domain-Driven Transformation besteht aus vier Schritten, die uns von der Analyse des aktuellen Zustands zu einer fachlichen Vision der Architektur führen. Anhand des aktuellen Zustands bestimmen wir die Reihenfolge der Umbaumaßnahmen, um zügig und mit einem stets einsetzbaren System voranzukommen.

Zielpublikum: Architekten, Entwickler, Projektleiter, Manager
Voraussetzungen: Erfahrung mit Softwareentwicklung
Schwierigkeitsgrad: Advanced

Eric Evans' Big Blue Book has a chapter titled "closure of operations", largely ignored by the community and subsequent works on DDD. This is tragic, as closure of operations is one of the most powerful techniques for domain modeling. A concept imported from functional programming, it makes for flexible and long-lived domain models with the help of combinators - operations that build big domain objects from smaller ones recursively. This is refreshing alternative to the rigid hierarchical taxonomies that often result from naive application of DDD modeling techniques "close to the domain", and which require continual adjustments and extensions. The talk shows what "closure" is and how you can harness it in your project.

"Closure of operations" applies abstraction over rigid models. It avoids common problems of overabstraction through a systematic process and the use of simple mathematical principles. The talk will also cover these.

Target Audience: Developers, Architects
Prerequisites: Basic DDD
Level: Advanced

Auf der grünen Wiese lässt sich leicht eine modulare Anwendung schreiben. Was aber, wenn es – wie leider so häufig in der Praxis – einen bestehenden, historisch gewachsenen Monolithen gibt, der schon einmal bessere Tage gesehen hat? Wie kann die Lücke zwischen dem alten monolithischen Architekturansatz zu einer modernen, modularen Architektur geschlossen werden, die ggf. in Microservices mündet?

Diese Session bietet eine praxisnahe Einführung in bewährte Methoden und Strategien, um eine Migration erfolgreich zu bestreiten. Wie kann ich Event Storming zum Finden von Modulgrenzen einsetzen? Wann und wie wende ich das Strangler Fig Pattern an? Wie teste ich einen Monolithen, wenn nicht mehr viel Wissen über Implementierungsdetails vorhanden ist? Diese und andere Fragen werden beantwortet.

Zielpublikum: Architekten, Entwickler, Projektleiter
Voraussetzungen: Erfahrungen mit monolithischer Legacy-Software
Schwierigkeitsgrad: Advanced

EventStorming, collaborative modelling, bounded context canvas - now what?

Did you ever feel like you're standing in front of a mountain of cloud tools and implementation options, with a well-designed domain model, but no idea where to start? Or are you fully equipped with technical understanding and cloud experience, but deeply unsure how to "cut" your system for good modularization?

Fear not, because this workshop will introduce you to a solid set of tried and proven methods and tools, that will help you to fill the gap!

Working in ensembles, we will breeze through the creative process - from EventStorming to automated deployments using Infrastructure as Code - to highlight a good path through the cloud jungle, and give you a jump start into your journey to serverless.

Maximum number of participants: 16

Target Audience: Developers, Architects
Prerequisites: A solid programming experience is helpful
Level: Advanced