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