Domain-driven Design (DDD) steht für eine Vielzahl an Techniken wie strategisches DDD, taktisches DDD und kollaborative Modellierung. Dieser Vortrag gibt einen Überblick über das DDD-Universum. Dabei stellt er nicht nur die verschiedenen Konzept vor. Er zeigt außerdem auch die jeweiligen Vor- und Nachteile der Praktiken auf und weist auf die typischen Fallstricke hin - und wie man sie vermeiden kann.

Zielpublikum: an Software-Architektur Interessierte
Voraussetzungen: Grundlegendes Verständnis von DDD
Schwierigkeitsgrad: Anfänger

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/eberhard.wolff

Gefühlt stand das Akronym WWW lange Zeit eher für Wild Wild West. Architekturmuster und -Prinzipien waren im Frontend oft die Ausnahme. Erst mit der letzten großen Frameworkwelle und dem Siegeszug von SPAs begann ein längst notwendiges Umdenken.
Neuere Technologien führen aber nicht automatisch zu einer besseren Architektur. Es gilt, nach wie vor, Architekturmuster gezielt einzusetzen. Eines der bekanntesten Muster im Domain-Driven Design ist die Hexagonale Architektur. Wann lohnt sich der Einsatz und wie funktioniert das in der Praxis?

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Frontend-Erfahrung und TypeScript-Kentnisse sind hilfreich
Schwierigkeitsgrad: Fortgeschritten

Beim Analysieren und Zerlegen von Legacy-Systemen nach DDD sind wir auf Domänen gestoßen, die einfach in Subdomänen aufgeteilt werden konnten, und auf Domänen, bei denen es deutlich schwieriger war. Auch das Alter und der Entwicklungsgrad einer Domäne haben Einfluss auf unsere Möglichkeiten, gute Subdomänen zu finden und die Legacy zu modularisieren. Inzwischen können wir diese Unterschiede beschreiben und haben verschiedene Domain Patterns gefunden und benannt. Ich freue mich auf Feedback und Diskussionen von den Zuhörer:innen.

Zielpublikum: Architekt:innen, Entwickler:innen, Business-Analyst:innen, Projektleiter:innen
Voraussetzungen: Projekterfahrung, Basiswissen in DDD
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
In den letzten Jahren haben wie eine Reihe von Domänen mit Subdomänen gesehen und mit DDD zerlegt. Ziel war natürlich immer, ein oder mehrere Softwaresysteme auf die Subdomänen aufzuteilen und eine sinnvolle Zerlegung des Softwaresystems anhand des Domänenschnitts zu erreichen. Mit der Zeit haben wir den folgenden Eindruck gewonnen:

1. Es gibt (Sub-)Domänen, die sich leichter in (Sub-)Subdomänen zerlegen lassen, und solche, bei denen es deutlich schwerer ist.
2. Es gibt Umsetzungen in fachliche Kontexte, die es leichter oder schwerer machen, das Legacy-System zu zerlegen.
3. Die Entwicklung der Domäne und der Software beeinflussen sich gegenseitig und die Legacy-Software ist je nach Entwicklungszustand anders zu zerlegen.

In diesem Talk werde ich unsere Überlegungen zu Domain Patterns und ihrer Umsetzung vorstellen und hoffe auf Diskussionen und Feedback.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/carola.lilienthal

Auch wenn ihr Microservices bereits umgesetzt habt, hängt ein wirklich erfolgreiches Produkt von technisch weiterführenden, methodischen und organisatorischen Themen ab. Wie stark ist die vertikale Idee ausgeprägt? Gibt es eine “Thinnest Viable Platform” und einen Pfad des geringsten Widerstands? Wie gut sind empirische Prozesse ausgeprägt und wie dezentral sind eure Entscheidungswege? In diesem Talk geben wir die Möglichkeit zum Self-Assessment und liefern damit Impulse, Microservices besser zu leben.

Zielpublikum: Architekt:innen, Entwickler:innen und alle, die an vertikalen Architekturen beteiligt sind
Voraussetzungen: Erfahrungen mit Microservices
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Viele Microservices-Anwendungen sind in Betrieb oder werden dort bereits weiterentwickelt und verbessert. Ob ein Microservices-basiertes System wirklich erfolgreich ist, hängt allerdings nicht nur von der technischen Migration ab, die initial geleistet wird. Um Versprechen in Bezug auf kürzere Release-Zeiten, bessere Agilität, höhere Innovationskraft und verbesserte Flexibilität und Skalierbarkeit einzulösen, braucht es weiterführende Impulse. Entwicklungsvorhaben und Teams müssen sich technisch, methodisch und organisatorisch weiterentwickeln.
In dieser Session zeigen wir einige weiterführende Themen, die unserer Erfahrung nach stark mit dem langfristigen Erfolg eines Microservices-Produkts korrelieren. Wie stark ist die vertikale Idee ausgeprägt? Gibt es eine “Thinnest Viable Platform” und einen Pfad des geringsten Widerstands? Wie gut sind empirische Prozesse ausgeprägt und wie dezentral sind die Entscheidungswege? Wie direkt und feinmaschig ist Feedback für qualitative Zielerreichung verfügbar? Aus einem Katalog von Fragen stellen wir hier einige vor. Sie führen allesamt zu einer evolutionären Idee der System- und Architekturentwicklung.
Um zum Nachdenken anzuregen und den Transfer auf den eigenen Kontext zu verbessern, liefern wir nicht nur Theorie, sondern zeigen auch Prüfmöglichkeiten für das eigene System und Reflexionsfragen für die eigene Organisation. Ein kleines Self-Assessment zieht sich durch den Talk und kann offline weiter vertieft werden. Insgesamt ein Schritt in die Richtung Microservices besser umzusetzen und die evolutionäre Idee dahinter besser zu leben.

Xin has lived and breathed DDD for more than a decade. Drawing on her experiences, Xin makes a case for DDD’s rising relevance in a post-modern world, where aging companies struggle with aging software, while adding new software and complexity to their IT portfolio. With good attractor effect DDD is evolving from a software-centric design discipline to a multi-dimensional toolbox. Join Xin to reflect together on, how DDD can help us sustain meaning and productivity in a reality of vast sociotechnical complexity and constant change.

Target Audience: Software Professionals, Architects, Leaders, Agile Practitioners, Change Agents, Facilitators
Prerequisites: Basic DDD understanding; Prior DDD experience is not a must but helps understand the deeper message
Level: Advanced

Extended Abstract:
What is the first thing that comes to mind when you hear the word DDD – Domain-Driven Design? The geeky technical patterns (Value object, Entity, Aggregate, etc.)? Walls decorated with colorful event storming stickies? A miracle cure to rescue change initiatives in large companies? Or are you thinking of a software development method born in the pre-cloud and pre-microservice era, which after 20 years is still struggling to gain traction?
Xin has lived and breathed DDD for more than a decade. In this talk, Xin makes a case for DDD’s rising relevance in a post-modern world, where aging companies struggle with aging software, while adding new software and complexity to their IT portfolio. The reflections will be grounded in solid DDD experiences and observations from the battlefield. With good attractor effect DDD can evolve from a software-centric design discipline to a multi-dimensional toolbox of thinking, modeling and collaboration techniques. You will be invited to explore DDD's value proposition and reflect upon how to leverage DDD’s strategic and tactical design approaches in your own context.
Globally, there is an increasing interest in DDD. Hope is evergreen for DDD to become a key ingredient in the magic potion for tackling the increasing complexity, not only at the heart of software, but also at the heart of sociotechnical organizations. How can DDD help us create meaning and productivity in a reality of multi-dimensional complexity and constant change? What’s in it for me? What’s in it for us?

Dass Event Storming eine Methode aus dem Domain-driven Design ist und man damit ein gemeinsames Verständnis der Fachlichkeit erreichen kann, ist vielen bekannt. Ich möchte in dieser Session darüber hinausgehen und euch zeigen, wie man Event Storming auch als eine Grundlage für einen guten Serviceschnitt nutzen kann.
In meinem Vortrag erläutere ich euch die Vorteile von Event Storming und verprobe die Methode anhand eines Praxisbeispiels. Das Ziel ist die Erstellung von Aggregaten, die die Basis für Bounded Contexts bilden.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Entscheider:innen, Product Owner:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Beim Finden der Bounded Contexts gehe ich auch darauf ein, was bei deren Kommunikation untereinander beachtet werden muss und wie man die Kommunikation gestalten kann, um später unabhängige Services realisieren zu können.

Das eigene Software-System in Microservices transformieren? Unabhängig davon, wir Softwerker sollten auch bestehenden Code entlang von Fachlichkeiten besser trennen. Wie gehen wir vor? Strangler-Pattern? Ist keine praktische Anleitung. Den Code in Geschäftsdomänen konzeptionell aufteilen und dann neu zu strukturieren? Klingt nach Big-upfront-Design.
Im Vortrag zeigen wir, wie man die bestehende Datenbasis über Code hinaus nutzen kann. Wie man z.B. die Features (im Issue-Tracker) oder die Beiträge der einzelnen Entwickler dabei berücksichtigt.

Zielpublikum: Architekt:innen, Projekt-/Technische Leiter:innen, Key Developer:innen, Manager:innen, Entscheider:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Das eigene Software-System in Microservices transformieren? Unabhängig davon, wir Softwerker sollten auch bestehenden Code entlang von Fachlichkeiten besser trennen. Wie gehen wir vor? Strangler-Pattern? Ist keine praktische Anleitung. Den Code in Geschäftsdomänen konzeptionell aufteilen und dann refactoren? Klingt nach Big-upfront-Design.
Im Vortrag zeigen wir, wie man die bestehende Datenbasis über Code hinaus nutzen kann. Wie man von Features (im Issue-Tracker) ausgeht, diese probeweise Domänen zuweist und deren Kopplungen (Überlappungen, Aufruf-Abhängigkeiten) im Code evaluiert. Damit dann den Refactoring-Bedarf lokalisieren und den Aufwand bewerten. Und wie automatisierte Refactoring-Vorschläge dabei eine Rolle spielen.
Die Herausforderungen sind die gleichen, wir müssen sie nur anders angehen.

Behandelte Problemstellungen:

1. Wie trennt man bestehenden Code nach fachlichen Verantwortlichkeiten?
2. Wie führt man das Ganze probeweise durch vor dem Refactoring/Coding?
3. Wie nutzt man die Features des Issue-Trackers dafür?
4. Wie nutzt man das Code-Repository dafür?
5. Wie wird der Refactoring/Redesign-Bedarf lokalisiert?
6. Wie bewertet man den Aufwand dafür?

Nutzen für den Teilnehmer:

1. Teilnehmer lernen ein praktisches Vorgehen zur Trennung des Codes entlang fachlicher Verantwortlichkeiten
2. Teilnehmer lernen mehr über architekturelle technische Schulden
3. Teilnehmer wohnen einem unterhaltsamen Vortrag bei :-)

In a microservices architecture, services shall be as loosely coupled as possible. Still, they need to communicate with each other in order to fulfill business requirements. Now there are so many questions around this communication (synchronous vs asynchronous, event-driven? what is the influence on the coupling of your services? ...?). This talk will help you answer these questions for your project. You will better understand not only the architectural implications but also the effect on the productivity of your teams.

Target Audience: Architects, Engineers, Developers
Prerequisites: Basic experience with distributed systems
Level: Basic

Extended Abstract:
In a microservices architecture, services shall be as loosely coupled as possible. Still, they need to communicate with each other in order to fulfill business requirements. Now there are so many questions around this communication:

1. What are the general possibilities to communicate? For example synchronous, asynchronous, or event-driven communication. What are the tradeoffs and which communication style should you prefer?
2. What is the influence on the coupling of your services? For example, asynchronous communication reduces temporal coupling between services.
3. What do I have to consider when selecting a certain communication style? For example, you need to apply certain resilience patterns if you want to use synchronous communication.

This talk will help you answer these questions for your project. You will better understand not only the architectural implications but also the effect on the productivity of your teams.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/bernd.ruecker

**TL, DR;** Embrace no-code to explore more models and throw most of those models away. You will quickly discover what works, and what matters, in the business process that you are automating. If it matters enough, you can extract it into a high-fidelity design in code.

Target Audience: Everyone with a stake in the software production process
Prerequisites: None
Level: Basic

Extended Abstract:
Many software projects still consume considerable resources, and take a long time before anything material is put in the hands of the end-user. At a smaller scale this happens with teams that have the ambition to adopt Domain-Driven Design principles but that lack the expertise and experience in how to approach the design process. There is a spectrum of mistakes. On one hand there is the lack of producing a meaningful and shared model that is able to unify the conflicts and handle the complexity that the messy world will serve the system. On the other end of that spectrum there is analysis paralysis: a model that never sees the light of day, because there is always a new case it cannot handle. If the team doesn't produce a meaningful model, or if it fails to put that model in front of experts early on, then the team robs itself of precious feedback. "Judge models by their usefulness" is a mantra that is difficult to live by, if the model isn't being used...
Despite warnings, teams design big architectures early on, to support even bigger ambitions of the organization they work for, but they forget that it's not the architecture that the end-user cares about. With every bit of structure that is added early on, the team reduces the degrees of freedom to evolve the system at a later point in time. In order to support long-lasting design that is attuned to the environment, teams should set architectural principles that allow for a helpful structure to emerge, regardless of the platform.
> **No code** has entered the chat...
For a while now, no-code vendors have been telling organizations that they shouldn't be limited by expensive software engineers to build systems that are useful. No-code aims to commoditize the software production process. Commodification of technology leads to value if it removes a limitation, but successful adoption only works if the rules and policies that initially helped us overcome the limitation are replaced as well. Practices such as DevOps have to be adopted in order to reap the benefits of the commodification of compute and storage in the cloud. In order to benefit from serverless, system components need to be decoupled through message-driven designs. In order to benefit from no-code, people have to organize around the software production process in a different way.
Within software engineering communities no-code has been dismissed as a fad, saying the need for writing code will never go away because the needs of most software systems are too complex to capture in a visual design environment. This viewpoint ignores the argument that software engineers act as a gatekeeper, a limitation for the stakeholder to get what they want. It is reductionist to say that no-code means no-code. No-code is as much about no-code, as wireless is about the absence of wires, or serverless is about the absence of servers. No-code means less boilerplate. And no-code does NOT mean no-model.
The inability to deliver meaningful results in a reasonable amount of time is never out of bad intent, it's the consequence of rigidity in the system of work. If there is no room for experiments, for error, for trying again, then we shouldn't be surprised if people attempt moonshots. But if we can reduce the cost of experiments, then we should be able to iterate more, learn faster, and as a consequence produce more value.
Let's explore how no-code is able to remove the time to market of our ideas to explore new models. Join this session to uncover which rules, policies, and practices around modeling and design need to be replaced in order to reap the benefits that no-code has to offer.

DDD ist momentan extrem populär, was zu falschen oder überzogenen Erwartungshaltungen führen kann. Diese werden in meinem Vortrag angesprochen. Ich stelle Ihnen anhand zahlreicher konkreter Beispiele aus der Praxis vor, wie man die meisten Probleme mit DDD vermeiden oder wie man mit DDD erfolgreich arbeiten kann. Dabei werden Facetten aus verschiedensten Blickwinkeln aufgegriffen: Entwicklung, Strategie, Fachmodellierung, Organisation und Agilität.
Der Vortrag soll ein Gespür für den Einsatz von DDD im Kontext Ihrer Organisation vermitteln.

Zielpublikum: Architekt:innen, Entwickler:innen, Manager:innen
Voraussetzungen: Grundverständnis von DDD
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Domain-Driven Design ist kein Patentrezept und löst kein Problem auf magische Weise. Die Herausforderungen und die Komplexität, die wir mit DDD zu bewältigen versuchen, sind schwierig und es gibt keinen einfachen Lösungsansatz. Nichtsdestotrotz gibt es eine wachsende Popularität und Wertschätzung für das Thema auf dem Markt, was zu überhöhten Erwartungen und schließlich zu Enttäuschungen führen kann.
Der Referent dieses Vortrags arbeitet seit 17 Jahren mit Domain-Driven Design an vielen Softwaresystemen und dieser Vortrag handelt von meinen Erfahrungen mit dem Scheitern. Glauben Sie mir: Ich bin oft gescheitert, aber es gibt immer eine Gelegenheit, etwas daraus zu lernen. Der Vortrag zielt darauf ab, Ihnen die Möglichkeit zu geben, aus den Fehlern von mir als Berater und den Teams/Organisationen, mit denen ich gearbeitet habe, zu lernen.
Der Vortrag behandelt Themen wie:

1. Domain-Driven Design im Wasserfall
2. Ignoranz für Code (aka nur Fokus auf strategisches Design)
3. Übermäßiger Gebrauch von Mustern um ihrer selbst willen
4. Kulturelle Implikationen
5. Cargo-Kult
6. Developer Experience
7. Eingeschränkte Verfügbarkeit von Fachexperten
8. Umgang mit etablierten Modellierungstechniken/Methoden
9. Unkenntnis über die Definitionen/Bedeutung von Heuristiken und Mustern

Dieser Vortrag zielt darauf ab, Ihnen eine Sensibilität für potenzielle Gefahren zu vermitteln, wenn Sie versuchen, DDD für Ihr Team und Ihre Organisation einzuführen, und wird nur reale Situationen beschreiben, die tatsächlich passiert sind. Jeder beschriebene Misserfolg wird mit einer Erkenntnis darüber einhergehen, wie man es besser machen kann.
Es handelt sich um einen interaktiven Vortrag, bei dem Ihnen, dem Publikum, Fragen und Umfragen (über ein Online-Tool) gestellt werden. Sie werden sich beteiligen können.

Bei Software steht oft komplexe Fachlichkeit im Mittelpunkt: Medikamentenstudien, Steuerberechnung, Teleskopsteuerung. Idealerweise wollen wir Softwerker ein Tool entwickeln, mit dem Fachexperten selbstständig Studien, Steuerberechnungen oder astronomische Beobachtungen beschreiben können, sodass sie direkt von Software ausführbar sind. Herauszufinden, wie man die Domäne vollständig und präzise beschreibt, ist dabei extrem wichtig. Der Vortrag liefert dafür konkrete Practices, die sich über Jahre bewährt haben, plus Anekdoten aus dem Projektalltag.

Zielpublikum: Product Owner:innen, Requirements Engineers, Architekt:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Ich beginne, indem ich nochmal 5 Minuten motiviere, warum man Tools bauen möchte, mit denen Fachler direkt programmieren/spezifizieren/modellieren wollen. Dann beschreibe ich kurz die drei Aspekte der Domänenanalyse: Sammeln, Denken und Validieren. Klingt trivial, ist es irgendwie auch, aber viele der konkreten Practices sind es nicht. Hier sind einige Stichworte, die ich betrachten werde:
Sammeln: Die (Nicht-)Rolle von schriftlichem Material, verborgene Sprachen finden, mit den richtigen Leuten reden, konsistente Terminologie, Workshops richtig durchführen, aktives Zuhören, Umgang mit Ungewissheit, Ergebnisse festhalten.
Denken: Abgrenzung und Tiefe der Domäne, Beseitigung von "historischem Müll", Test-Unterstützung, Plattformen, Hochs und Tiefs, das Wissen verbreiten
Validieren: Spiel-Implementierung der Domäne, Benutzer experimentieren lassen, Konzeptuelle Überprüfung, Umgang mit Feedback, Tolle Demos
Der Vortrag basiert auf dem Buch "How to Understand Almost Anything", das ich im letzten Jahr geschrieben habe.

**TL,DR**; In this course you will learn to map your business and technological landscape in such a way that a common language emerges to discuss strategic thinking and decision-making.
Max. number of participants: 13

Target Audience: Architects, Developers, Project Leaders, Decision Makers
Prerequisites: Basic theoretical knowledge of DDD
Level: Advanced

Extended Abstract:
Organizations face more and more complexity these days as a result of a mesh of products, services, technology and the people that work to build, operate and maintain them.
Domain-Driven Design helps us with solving problems the right way. But what helps us solve the right problem? How can we continuously validate our progress with people in "non-tech" roles? And what should we do when the world around us changes, which it always ends up doing? Is the plan we had still valid?

Imagine...
- Imagine having a map that helps you understand the ecosystem your organization is embedded in. A map that makes sense from both a technical and business perspective. With patterns that provide guidance about effective actions regardless of the specific domain you are working in. Wardley Mapping is that: it is a ubiquitous language around strategy and execution that helps you solve the right problem.

The course
- In this course you will learn to map your business and technological landscape in such a way that a common language emerges to discuss strategic thinking and decision making. It allows for scenario building, it teaches about bias and assumptions, and it comes packaged with a long list of ideas that may help in your situation.
The map can hint us what practices from DDD are beneficial in our situation. And it can serve as a context map too, except this one has meaning to businesspeople as well.
Using visualizations, strategies can be challenged and implementation options debated and weighed. As such, mapping is about the act and not merely the artifact. That is why this training is hands-on from the very start.

What to expect
- This class will emphasize practice over theory. Mapping with imperfect knowledge today is better than mapping with perfect knowledge next year. The course will teach you the basics and provides hooks into the theoretical aspects behind exercises.

Who should attend
- Anyone that wants to challenge the status quo of decision making under uncertainty in technology and business. No prior knowledge is required and your open attitude to learn new things will be an asset during the workshop.