Modern Software Architecture with the Architecture Hamburger en de

How to structure your program right? This has been a central question since the beginning of software development. Layers are a start, but not enough. Hexagonal, Onion, and Clean Architecture have joined the club together with DDD's Tactical Design and Pattern Languages. Great system design is not achieved with one of these alone. Putting all the ingredients together we can build the Architecture Hamburger – the combination that makes high quality software possible.

Moderne Software-Architektur mit dem Architektur-Hamburger en de

Wie strukturiert man ein Programm richtig? Dies ist seit Beginn der Software-Entwicklung eine zentrale Frage. Schichten sind ein Anfang, aber nicht genug. Modernere Stile sind Hexagonal, Onion und Clean Architecture. Auch Tactical Design und Pattern Languages helfen. Großartiges Systemdesign wird nicht nur mit einer dieser Zutaten erreicht. Nur wenn wir alle zusammenfügen, können wir den Architektur-Hamburger bauen – die Kombination, die qualitativ hochwertige Software möglich macht.

Domain Storytelling—Understanding Your Users by Drawing Pictures en de

Misunderstandings between developers and the business are a plague. Bad communication makes projects fail. This talk presents a remedy. The session's highlight will be a practical demonstration with the auditorium as an interview partner.

Domain Storytelling is a technique to transform domain knowledge into effective business software. It brings together domain experts and development teams to: (a) understand the domain of a software system, (b) find microservices boundaries, and (c) talk about requirements.

We let domain experts tell us stories about their tasks. While listening, we record the stories using an easy-to-understand pictographic language.

The domain experts can see immediately whether we understand their story correctly. After very few stories, we are able to talk about the people, processes, and events in that domain.

The talk is aimed at everyone involved or interested in software development, including non-technical people.

My book on the topic has just been published in Vaughn Vernon's Addison-Wesley Signature Series. See https://domain-storytelling.org/book

Anwender verstehen mit Domain Storytelling en de

Missverständnisse zwischen Entwicklern und dem Fachbereich sind eine Plage. Schlechte Kommunikation lässt Projekte scheitern. Dieser Vortrag stellt eine Abhilfe vor (einschließlich einer praktischen Demonstration mit Beteiligung des Auditoriums).

Domain Storytelling ist eine Technik, um Domänenwissen in effektive Business-Software zu verwandeln. Sie bringt Domänenexperten und Entwicklungsteams zusammen, um: (a) die Domäne eines Softwaresystems zu verstehen, (b) die Grenzen von Microservices zu finden und (c) über Anforderungen zu sprechen.

Wir lassen uns von Domänenexperten Geschichten über ihre Aufgaben erzählen. Während wir zuhören, zeichnen wir die Geschichten in einer leicht verständlichen, piktografischen Sprache auf.

Die Domänenexperten können sofort sehen, ob wir ihre Geschichte richtig verstehen. Nach wenigen Geschichten sind wir in der Lage, über die Menschen, Prozesse und Ereignisse in dieser Domäne zu sprechen.

Der Vortrag richtet sich an alle, die mit Softwareentwicklung zu tun haben oder sich dafür interessieren, auch an Nicht-Techniker.

My book on the topic has just been published in Vaughn Vernon's Addison-Wesley Signature Series. See https://domain-storytelling.org/book

The Joy of Multiple Models—Structuring Monoliths and Microservices with Domain-Driven Design en de

Software development is model building. We rebuild a part of the world as a program in Java and improve it by doing so. A traditional approach is to reproduce the domain as accurate in every detail as possible. But is this the actual goal of models? If we look close enough, we will see that a model is the exact oposite—a model is actually an abstraction of the reality in which only the essential is transferred. The inessential is left out of the model. What parts of the reality are essential or inessential is defined by the domain.

A simple model is easier to understand than a complicated one. Therefore, it is a good idea to break a complex reality into multiple simple models. Exactly this effect is what microservices and DDD with its strategic design take advantage of. Here instead of one complex company-wide model we build several small models that are easy to understand.

In this talk we look into the tools that are available to build good models and to divide the domain in a way that we can work with several teams independently from each other.

Convincing Colleagues and Bosses of Good Ideas and New Technologies en de

At a conference like the XXX you learn great new things. In every session you think, “I can't wait to try these new language features.” Or, “This new framework is just the thing for our problem.” Or, “With those agile techniques, we need fewer meetings and I finally have more time for programming.”

Then when you get back from the conference and come into the office on Monday, you tell all your colleagues about it full of euphoria. And unfortunately they don't like it at all. Tey say, “Nobody needs this newfangled stuff.” Or, “This is nothing new. We've always done it like that.” And half a year later you look back and think: “We haven't implemented any of my nice ideas”.

It doesn't have to be like that! In this talk I will look at what we techies can learn from psychologists, sociologists & co. With the right (soft) tools we can convince bosses and colleagues of good ideas for the benefit of all of us.

We look into the toolbox that Fearless Change, Communication Patterns, Reframing, Secrets of Consulting, Nonviolent Communication and even the interrogation techniques of the secret services offer us.

Carving Microservices out of the Monolith with Domain Storytelling en de

For a microservices architecture to be succesful it is crucial to have the right boundaries between the microservices. But where are the right boundaries? I would like to present a tool that helps us answer this question.

Domain Storytelling (www.domainstorytelling.org) means that we let our users tell us stories about their work. While listening, we record the stories using a pictographic language. The experts can immediately see if we understand their story. After very few stories, we understand the language of our users and find different areas of the domain. Each of these areas (called a subdomain) is a good candicate to become a microservice in our architecture.

In this talk I show how to find subdomains and which heuristics can help us.

The joy of multiple models – Wie man mit Domain-Driven Design einen Monolithen zerschneidet en de

Softwareentwicklung ist Modell-Bildung. Wir bauen einen Teil der Wirklichkeit als Programm nach und verbessern sie so. Ein traditioneller Ansatz ist, die Domäne als Ganzes möglichst detailgenau nachzubilden. Aber ist das eigentlich der Zweck von Modellen? Wenn wir genau hinschauen, bemerken wir, dass ein Modell eigentlich genau das Gegenteil ist – Ein Modell ist nämlich eine Abstraktion der Wirklichkeit, in die nur das Wesentliche übertragen und das Unwesentliche weggelassen wird. Was wesentlich und was unwesentlich ist, ergibt sich aus dem Kontext.

Ein einfaches Modell ist leichter zu verstehen als ein kompliziertes. Deshalb ist es eine gute Idee, von einer komplizierten Wirklichkeit mehrere einfache (und einfach verständliche) Modelle zu bilden. Genau diesen Effekt machen sich Microservices und DDD mit seinem Strategischen Design zu nutze. Hier werden statt dem einen großen unternehmensweiten Modell mehrere kleine gut verständliche Modelle gebildet.

In diesem Talk betrachten wir, welche Mittel uns zur Verfügung stehen, um gute Modelle zu bauen und die Domäne so aufzuteilen, dass wir auch mit mehreren sinnvoll und unabhängig arbeiten können.

Kollegen und Chefs von guten Ideen und neuen Technologien überzeugen en de

Auf einer Konferenz wie der XXX lernt man tolle neue Sachen kennen. In jeder Session denkt man: »Diese Sprach-Features muss ich unbedingt mal ausprobieren.« Oder: »Das neue Framework ist genau das richtige für unser Problem.« Oder: »Mit jenen agilen Techniken brauchen wir weniger Meetings und ich hab endlich mehr Zeit fürs Programmieren.«

Wenn man dann von der Konferenz zurück ist und am Montag ins Büro kommt, erzählt man allen Kollegen voller Euphorie davon. Und die finden das leider gar nicht toll. Sagen: »Diesen neumodischen Kram braucht kein Mensch«. Oder: »Das ist doch nix neues. das haben wir schon immer so gemacht.« Und ein halbes Jahr später schaut man zurück und denkt: »Wir haben keine meiner schönen Ideen umgesetzt«.

Das muss nicht sein! In diesem Vortrag betrachte ich, was wir Techies von Psychologen, Soziologen & co lernen können. Mit den richtigen (soften) Tools können wir zum Wohle aller Chefs und Kollegen von guten Ideen überzeugen.

Wir schauen in den Werkzeugkasten den uns Fearless Change, Communication Patterns, Reframing, Secrets of Consulting, Gewaltfreie Kommunikation und sogar die Verhörtechniken der Geheimdienste bieten.

It’s All About the Domain, Honey—DDD as Basis for Great Architecture en de

To build software, we use great technologies, programming languages, and tools. And we have a lot of fun programming in this technical environment. But we must not forget that the most important point for a successful project is not the technology but the *domain*! To understand the domain we need a common language with the domain experts. Also, if we don't reflect the domain model in the software and its architecture, it will not help our users doing their work.

It is easy for developers to fall into the trap of focussing on technology instead of the domain. To prevent you from this, I will show in this talk how Domain-Driven Design (DDD) can help you to gather the domain knowledge and transform it into a Ubiquitous Language. To do this we use techniques like Interviews, Domain Storytelling, and Event Storming.

In practice it is not easy to decide how to divide up the domain and develop microservices for it. Here the DDD pattern Bounded Context can help us. It shows us where vertical cuts can be made.

Using these tools together with the Building Blocks of DDD enables us to build an architecture that represents the domain and makes our users happy.

It's all about the domain, honey – Fachliche Architektur mit DDD en de

Beim Bauen von Software werden tolle Technologien, Programmiersprachen und Tools eingesetzt. Das ist gut und richtig. Aber leider wird dabei oft aus den Augen verloren, dass das Entscheidende für den Projekterfolg nicht die Technik, sondern die *Fachlichkeit* ist. Um die Fachlichkeit (=Domäne) verstehen zu können, brauchen wir eine gemeinsame Sprache mit den Fachexperten. Außerdem: wenn wir in der Software und ihrer Architektur nicht das fachliche Modell abbilden, dann wird sie unseren Anwendern nicht bei Ihrer Arbeit helfen. Davor schützt uns keine Technologie der Welt.

Als Informatiker kann man leicht in die Falle tappen, sich auf Technologie statt auf Fachlichkeit zu fokussieren. Um das zu verhindern, zeige ich in diesem Vortrag, wie man mit Domain-Driven Design (DDD) das Wissen um die Fachlichkeit lernen und in eine Ubiquitous Language übertragen kann. Dazu werden Techniken wie Interviews, Domain Storytelling und Event Storming eingesetzt.

In der Praxis ist es schwierig zu erkennen, wie wir unsere Domäne schneiden und daraus Microservices entwickeln können. Hierbei kann uns das Prinzip der Bounded Contexts aus DDD helfen. Es gibt uns Hilfestellung wo vertikale Schnitte sinnvoll sind.

Setzt man diese Techniken gemeinsam ein, dann kann man die Architektur von Software-Systemen so bauen, dass sie die Fachlichkeit darstellt und unsere Anwender glücklich macht.

Microservices aus dem Monolithen schneiden mit Domain Storytelling en de

Damit eine Microservices-Architektur erfolgreich sein kann, ist es elementar wichtig, die richtigen Grenzen zwischen den Microservices zu ziehen. Aber wo sind die richtigen Grenzen? Ich möchte ein Werkzeug präsentieren, das uns hilft, diese Frage zu beantworten.

Domain Storytelling heißt, dass wir unsere Anwender uns Geschichten über ihre Domäne erzählen lssen. Während wir zuhören, zeichnen wir die Domain Stories vor den Augen der Fachexperten mit einer Bildsprache auf. Dadurch können alle Beteiligten unmittelbar sehen, ob sie richtig verstanden wurde. Schon nach wenigen Domain Stories verstehen wir die Sprache unser Anwender und finden unterschiedliche Bereiche in unser Fachlichkeit. Jeder dieser Bereiche (eine sog. Subdomain) ist ein guter Kandidat​ dafür, ein Microservice in unser Architektur zu werden.

In diesem Vortrag zeige ich, wie man Subdomänen findet und welche Heuristiken uns dabei helfen.

Using Record Types to Build Better Domain Models en de

Not everything in the world is an object. That’s why DDD defines different design patterns, like Entity, Value Object, Repository, etc. Lately, Oracle and Microsoft have equipped their languages with Record Types (Java 14, C# 9) and Record Structs (C# 10). They help in many cases to implement DDD’s Value Objects. That way we can express our domain in a natural way and reduce boilerplate code.

In this talk we will look at:

* What’s behind the motto “Codes Like a Class—Works Like an Int.”
* Why immutabilty leads to less failures.
* The new syntax to support record types.
* How value types are implemented in other languages.
* And most important: how record types can help us to provide a better domain model.

Mit Record Types zu besseren Domänenmodellen en de

Nicht alles auf der Welt ist ein Objekt. Deshalb definiert DDD verschiedene Entwurfsmuster, wie Entity, Value Object, Repository, usw. In letzter Zeit haben Oracle und Microsoft ihre Sprachen mit Record Types (Java 14, C# 9) und Record Structs (C# 10) ausgestattet. Diese helfen in vielen Fällen bei der Implementierung der Value Objects aus DDD. Auf diese Weise können wir unsere Domäne auf natürliche Weise ausdrücken und Boilerplate-Code reduzieren.

In diesem Vortrag werden wir uns ansehen:

* Was sich hinter dem Schlachtruf "Codes Like a Class – Works Like an Int" verbirgt.
* Warum Immutability zu weniger Fehlern führt.
* Die neue Syntax zur Unterstützung von Record Types.
* Wie Werttypen in anderen Sprachen implementiert werden.
* Und das Wichtigste: wie Record-Typen uns helfen können, ein besser verständliches Domänenmodell zu bauen.

From Domain to Code with Domain Storytelling en de

We all love programming. But programming is not an end in itself. And how do we actually know, what we should program? For that we need a tool to learn about the domain.

Domain Storytelling is a collaborative modeling method. It brings together domain experts and development teams. It means that we let our users tell us stories about their work. While listening, we record the stories using a pictographic language.

The experts can see immediately if we understand their story. After very few stories, we understand the language of our users and can build a domain model from it and implement this in the programming language of our choice.

Von der Domäne zum Code mit Domain Storytelling en de

Wir alle lieben Programmieren. Nur ist Programmieren ist ja kein Selbstzweck. Und woher wissen wir eigentlich, was wir programmieren sollen? Dazu brauchen wir ein Werkzeug mit dem wir die Domäne und Ihre Sprache kennenlernen können.

Domain Storytelling (www.domainstorytelling.org) heißt, dass wir unsere Anwender Geschichten von ihren Aufgaben erzählen lassen. Beim Zuhören zeichnen wir die Geschichten mit einer grafischen Sprache auf. Unsere Fachexperten können direkt verstehen, ob wir sie richtig verstehen und was wir noch falsch verstehen. Nach nur wenigen Stories verstehen wir die Sprache unserer Anwender und können ein Domänenmodell daraus bauen und implementieren.

Workshop: Domain-Driven Design hands-on en de

In the times of microservices, it becomes clear how important Domain-Driven Design (DDD) still is. Only with strategic design (i.e. DDD on a large scale) and the division of the domain into bounded contexts can a sensible cut be found for the microservices.

But also Tactical Design (i.e. DDD on a small scale) with the Ubiquitous Language and the "Building Blocks" Entities, Value Objects, Aggregates, Services and co. have lost nothing of their relevance.

In this workshop we will take a day to take a closer look at DDD. The workshop consists of alternating lecture, discussion and exercises.

***

The structure will be such that we first give an overview of DDD and then look at the individual topics in detail. In doing so, we will approach DDD from the outside in. Content structure:
1. introduction and overview
2. getting to know the domain
3. splitting up the domain
4. learning the domain language
5. model the domain
6. implement the domain model

Workshop: Domain-Driven Design hands-on en de

In den Zeiten von Microservices wird klar, wie wichtig Domain-Driven Design (DDD) nach wie vor ist. Denn nur mit Strategischem Design (also DDD im Großen) und dem Aufteilen der Domäne in Bounded Contexts kann ein sinnvoller (nämlich fachlicher) Schnitt für die Microservices gefunden werden.

Aber auch Taktisches Design (also DDD im Kleinen) mit der Ubiquitous Language und den "Building Blocks" Entities, Value Objects, Aggregates, Services und co. haben nichts an Aktualität verloren.

In diesem Workshop nehmen wir uns einen Tag Zeit um DDD näher anzuschauen. Der Workshop besteht aus abwechselnd Vortrag, Diskussion und Übungen.

***

Der Aufbau wird so sein, dass wir zunächst einen Überblick über DDD geben und uns dann die einzelnen Themen detailiert betrachten. Dabei nähern wir uns DDD gewissermaßen von außen nach innen. Inhaltlicher Aufbau:
1. Einführung und Überblick
2. Domäne kennenlernen
3. Domäne aufteilen
4. Sprache lernen und bauen
5. Domäne modellieren
6. Modell implementieren

Monolith Microservice Metamorphosis en de

With a real world example I will show the typical challenges (and how to overcome them) on the journey from the old monolithic, on-premise, legacy-code world into the new cloud-based, domain-driven, microservices world. The talk will show patterns and refactorings.

Monolith-Microservice-Metamorphose en de

Anhand eines Realweltbeispieles zeige ich die typischen Probleme auf der Reise von der alten, monolithischen Legacy-Welt in die neue Cloud-basierte, Domain-Driven, Microservices-Welt. Der Talk zeigt Domain-Driven Refactorings und Patterns wie Strangler Fig Application.

From Legacy to Cloud—Mistakes You Don’t Want to Make Your Own en de

Come and hear the story of a company that is on the journey from the old monolithic, on-premise, waterfall world to the new modular, agile, domain-driven, multi-tenant, cloud-based microservices world. The challenges come from different directions: both technical and organizational aspects have to mastered. The domain has to be understood, so that the system can be structured right. The big bang has to be avoided.

In this talk we will look at how our “fictional” company has struggled with and finally overcome those challenges.

Von Legacy in die Cloud – Fehler die Du nicht selbst machen willst en de

Hört die Geschichte eines Unternehmens, das sich auf dem Weg von der alten monolithischen On-Premise-Wasserfall-Welt zur neuen modularen, agilen, domain-driven, mandantenfähigen, cloudbasierten Microservices-Welt befindet. Die Herausforderungen kommen aus verschiedenen Richtungen: Sowohl technische als auch organisatorische Aspekte müssen gemeistert werden. Die Domäne muss verstanden werden, damit das System richtig strukturiert werden kann. Der große Knall muss vermieden werden.

In diesem Vortrag werden wir uns ansehen, wie unser »fiktives« Unternehmen mit diesen Herausforderungen kämpft und sie schließlich überwindet.

Living Architecture Documentation with xMolecules en de

Good architecture contains patterns. But which pattern does a given class follow? To express this directly in the code is the task of xMolecules. xMolecules is a framework-agnostic library that allows for the following:

- Annotate common architectural concepts (like layers or DDD building blocks) directly in source code. This makes it easier for human readers to understand which pattern a piece of code follows.
- Verify that rules regarding the implementation of these patterns are followed, e.g. with JQAssistant, ArchUnit(.NET), PHPStan.
- Derive the necessary technical integration and appropriate documentation. So, code generators can use the info to reduce boilerplate code.

For different programming languages (so far Java, .net, and PHP) the possibility is given to annotate code accordingly. In this talk this brand new library will be presented by one of its creators.

Lebendige Architekturdokumentation mit den xMolecules en de

Gute Architektur enthält Muster. Aber welchem Muster folgt eine gegebene Klasse? Das explizit auszudrücken ist die Aufgabe der xMolecules. xMolecules ist eine Framework-unabhängige Bibliothek die folgendes erlaubt:

- Darstellen verbreiteter architektonischer Konzepte (wie Schichten oder DDD-Building-Blocks) direkt in Code. So wird es für den menschlichen Leser leichter zu verstehen, welchem Muster ein Stück Code folgt.
- Überprüfen, ob Regeln bezüglich der Implementierung dieser Muster eingehalten werden, z. B. mit JQAssistant, ArchUnit(.NET), PHPStan.
- die nötige technische Integration, sowie entsprechende Dokumentation abzuleiten. Damit können Code-Generatoren die Infos nutzen um Boilerplate-Code zu reduzieren.

Für verschiedene Programmiersprachen (bisher Java, .net, PHP) wird die Möglichkeit gegeben, Code entsprechend zu annotieren. In diesem Talk wird die brandneue Bibliothek von einem ihrer Macher präsentiert.

Domain-Driven Transformation—How to Bring (Back) Sustainable Architecture to Legacy and Monoliths en de

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. I 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.

Domain-Driven Transformation – Legacy-Software und Monolithen tragfähige Architektur (zurück-)geben en de

Wie man ein neues Projekt auf der grünen Wiese beginnt und dabei eine saubere Architektur baut, das wissen wir heute ganz gut. Aber die meisten von uns arbeiten ja in Projekten, die schon lange da sind und deren Architektur (vorsichtig gesagt) nicht mehr ganz so schön ist. »Monolith« und »Big Ball of Mud« sind die wenig schmeichelhaften Titel, die solchen Systemen verpasst werden.

In diesem Talk zeige ich, wie wir hier (wieder) Struktur einführen können. Jedes System ist hier anders, deswegen ist es wichtig zunächst zu erkennen wo man steht. Dann müssen die richtigen Schritte unternommen werden. Ich präsentiere einen Katalog von Refactorings, aus man wählen kann und Heuristiken, was die richtige Wahl ist.

Der Katalog enthält Refactorings gegen: Big-Ball-of-Mud-Architektur, Anämisches Domänenmodell und schlecht organisierte Teams.

Model Pollution Is Bad—What Can I Do Against It? en de

Technical code and business code should be kept separate. That seems like a simple architecture rule. But it is violated in virtually every real project. Even current frameworks like Spring, Hibernate and co. easily contaminate our domain models.

In this talk, we look at ways out of this misery and when and how much pollution might nevertheless be acceptable. This will be helped by

- an understanding of the Domain Logic Patterns: Transaction Script, Table Module, Domain Model,
- the architecture styles Onion, Clean and Hexagonal Architecture and
- tactical design from DDD.

Fachmodellverschmutzung ist schlecht – was kann ich dagegen tun? en de

Technischer und fachlicher Code gehören getrennt. Eine scheinbar einfache Architekturregel, die in quasi jedem realen Projekt verletzt wird. Auch aktuelle Frameworks wie Spring, Hibernate und co. verschmutzen leicht unsere Domänenmodelle.

In diesem Vortrag schauen wir auf Auswege aus dieser Misere und wann wieviel Verschmutzung vielleicht doch in Ordnung ist. Dabei helfen uns:

- ein Verständnins der Domain Logic Patterns: Transaction Script, Table Module, Domain Model,
- die Architekturstile Onion, Clean und Hexagonal Architecture und
- taktisches Design aus DDD.