Komplexitätsreduktion durch DDD: Teams optimal durch klare Fachlogik koordinieren en

In unserer praxisnahen Präsentation nehmen uns Mathias Esschold (Lead Architect bei der EnBW) und Nils Hyoma (Manager bei MHP - A Porsche Company) mit auf eine umfassende Erkundung der Herausforderungen in der skalierenden Produktentwicklung, insbesondere am Beispiel von SAFe. Wir illustrieren, wie Domain-Driven Design (DDD) dazu in der Lage ist, die vielschichtige Komplexität auf effiziente Weise zu bewältigen. Im Fokus steht dabei die Kunst, Teams ausschließlich durch klare Fachlogik zu koordinieren, und wir starten unsere Reise mit einer prägnanten Einführung in DDD.

Unsere Expedition führt uns durch die fachliche Zerlegung von Anforderungen, die strategische Planung des fachlichen Austauschs zwischen Stakeholdern und Mitgliedern des agilen Teams, die iterative Gestaltung technischer Systeme ohne tiefgreifende Technologiekenntnisse und die gezielte Steuerung des Austauschs zwischen Stakeholdern und Entwicklern.

Während dieser Reise teilen wir nicht nur praxisnahe Einblicke und Herausforderungen, sondern auch bewährte Methoden, die wir aus unserer Erfahrung in skalierenden Entwicklungen gewonnen haben. Ziel ist es, zu veranschaulichen, wie wir mithilfe von DDD eine klare Struktur schaffen und Effizienz in der skalierenden Produktentwicklung erreichen können.

Follow the Twin Peaks - Mehr Domänenwissen gleich bessere Softwarearchitektur de en

Fahrzeug, Bestellung, Auftrag und Kunde. Alles klar, das kennen wir! Die im Planning gefühlte Klarheit endet, wenn Entwickler:innen bei der Implementierung von User Stories auf offene Fragen stoßen. Ein schnelle Klärung komplexer Fragen oder Annahmen seitens der Entwickler:innen führen oft nicht zum Erfolg.

Das Ergebnis: Die software-technische Realisierung deckt sich nicht mit den wirklichen fachlichen Anforderungen und es muss nachgearbeitet werden. In der Folge steigen Aufwand und Kosten. Das Projekt befindet sich in einer Abwärtsspirale aufgrund fehlenden Domänenwissen und einer daraus resultierender Softwarearchitektur, die die Domäne nicht unterstützen kann.

Die Twin Peaks sind ein Modell, dass die Wichtigkeit des Zusammenspiels zwischen Anforderungen und Architektur beschreibt. Die Abwärtsspirale wird durchbrochen, indem wir die Twin Peaks von der Spitze an, mit Hilfe von Domain Storytelling, hinabsteigen. In diesem Talk stelle ich euch Domain Storytelling vor und wie diese Methode dabei hilft das Twin Peaks Model in der Praxis zu leben. In drei Sprints erarbeiten wir gemeinsam das erste Inkrement unseres Softwareprodukts. Dabei wird die Methodik Domain Storytelling, Tipps und Tricks für die Moderator:in sowie der Übergang zur Softwarearchitektur interaktiv vermittelt. Denn vermutlich liegt es nun an dir, die entscheidenden Impulse zur Verbesserung der Situation in deinem Projektkontext zu setzen.

Die Twin Peaks sind ein Modell, dass die Wichtigkeit des Zusammenspiels zwischen Anforderungen und Architektur beschreibt. Domain Storytelling hilft das Twin Peaks Model in der Praxis zu leben. In drei Sprints erarbeiten wir gemeinsam das erste Inkrement eines praxisnahen Anwendungsfall. Dabei wird die Methodik Domain Storytelling, Tipps und Tricks für die Moderator:in sowie der Übergang zur Softwarearchitektur interaktiv vermittelt. Du erhälst ein tiefgehendes Verständnis dafür, wie du mit dieser Methode entscheidende Impulse zur Verbesserung der Situation in dein Projekt erzielen kannst.

Follow the Twin Peaks - More domain knowledge leads to better software architecture de en

Spare part, order, offer, and customer. All right, we know that! The clarity felt in planning ends when developers encounter open questions during the implementation of user stories. A quick clarification of complex questions or assumptions from the developers often does not lead to success. The result: The software-technical realization does not match the real business requirements and rework is necessary. As a result, effort and costs increase. The project finds itself in a downward spiral due to a lack of domain knowledge and resulting software architecture that cannot support the domain.

The Twin Peaks is a model that describes the importance of the interplay between requirements and architecture. We break the downward spiral by starting at the top of the Twin Peaks and moving down using Domain Storytelling.

In this talk, I will introduce Domain Storytelling and how this method helps to live the Twin Peaks Model in practice. In three sprints we will work together on the first increment of the use case "Ordering spare parts". The methodology Domain Storytelling, tips and tricks for the facilitator as well as the transition to the software architecture will be conveyed interactively. After all, it is probably now up to you to set the decisive impulses for improving the situation in your project context.

Workshop Flexible Softwarearchitektur - Clean und Hexagonal Architecture verstehen und anwenden de

Flexible Geschäftsmodelle benötigen flexible Softwarearchitekturen. Setzt die Softwarearchitektur die Bedürfnisse der fachlichen Domäne optimal um, können entscheidende Wettbewerbsvorteile erzielt werden. Neben einer fachlichen Ausrichtung der Softwarearchitektur werden Architekturmuster benötigt, die "Design for Change" und weiterführend "Flexibility by Design" unterstützen.

Die Clean und Hexagonal Architecture versprechen eine Entkopplung der fachlichen Domäne von infrastrukturellen Aspekten. Dies ist die Basis für eine flexible Softwarearchitektur. Die zu Grunde liegende Idee von Ports und Adapters ist mächtig und hilft technische, fachliche sowie organisatorische Flexibilität in der Anwendungsarchitektur zu realisieren.

Im Workshop lernen Sie Flexibilitätsanforderungen aus der Praxis kennen und erhalten die Möglichkeit Anforderungen aus ihrem Projektkontext mit Hilfe von Qualitätsszenarien zu beschreiben. Weiter folgt eine detaillierte Einführung in die Clean und Hexagonal Architecture. Gemeinsam wollen wir verstehen, wann der Einsatz dieser Architekturmuster zielführend ist und wie Sie diese auf der technischen Ebene realisieren. Im Workshop werden wir Codebeispiele in Java analysieren und Vorteile, Nachteile sowie Kompromisse diskutieren. Mit Übungen wird das Verständnis für die technische Umsetzung vertieft. Sie erhalten alle Trainingsmaterialien und Beispiele und haben die Möglichkeit die Thematik hinterher im Selbststudium zu vertiefen.

Im Workshop "Flexible Softwarearchitektur" lernen Sie Flexibilitätsanforderungen aus der Praxis kennen und erhalten die Möglichkeit Anforderungen aus ihrem Projektkontext mit Hilfe von Qualitätsszenarien zu beschreiben. Weiter folgt eine detaillierte Einführung in die Clean und Hexagonal Architecture. Gemeinsam wollen wir verstehen, wann der Einsatz dieser Architekturmuster zielführend ist und wie Sie diese auf der technischen Ebene realisieren. Im Workshop werden wir Codebeispiele in Java analysieren und Vorteile, Nachteile sowie Kompromisse diskutieren. Mit Übungen wird das Verständnis für die technische Umsetzung vertieft. Sie erhalten alle Trainingsmaterialien und Beispiele und haben die Möglichkeit die Thematik hinterher im Selbststudium zu vertiefen.

Flexible Softwarearchitektur mit der Clean Architektur de en

Flexible Geschäftsmodelle benötigen flexible Softwarearchitekturen. Setzt die Softwarearchitektur die Bedürfnisse der fachlichen Domäne optimal um, können entscheidende Wettbewerbsvorteile erzielt werden. Neben einer fachlichen Ausrichtung der Softwarearchitektur werden Architekturmuster benötigt, die "Design for Change" und weiterführend "Flexibility by Design" unterstützen.

Die Clean Architecture verspricht eine Entkopplung der fachlichen Domäne von infrastrukturellen Aspekten. Dies ist die Basis für eine flexible Softwarearchitektur. Die zu Grunde liegende Idee von Ports und Adapters ist mächtig und hilft technische, fachliche sowie organisatorische Flexibilität in der Anwendungsarchitektur zu realisieren.

Im Vortrag Flexible Softwarearchitektur lernen Sie Flexibilitätstreiber aus der Praxis und die Clean Architecture als Architeturmuster für "Flexibility by Design" kennen. Sie erhalten ein tiefgehendes Verständnis und können Einschätzen wann der Einsatz der Clean Architecture zielführend ist und wie Sie diese auf der technischen Ebene realisieren. Anhand von Codebeispielen in Java diskutieren wir Vorteile, Nachteile sowie Kompromisse für pragmatische Lösungen.

Im Vortrag Flexibile Softwarearchitektur lernen Sie Flexibilitätstreiber aus der Praxis und die Clean Architecture als Architeturmuster für "Flexibility by Design" kennen. Sie erhalten ein tiefgehendes Verständnis und können Einschätzen wann der Einsatz der Clean Architecture zielführend ist und wie Sie diese auf der technischen Ebene realisieren. Anhand von Codebeispielen in Java diskutieren wir Vorteile, Nachteile sowie Kompromisse für pragmatische Lösungen.

Sustainable growth with fluid teams and Domain-driven Design en de

Scrum is the framework for developing software systems in complex and almost chaotic environments. Through skillful product ownership, development teams will gain more and more domain and technical knowledge. When set up cross-functionally, they develop highly productive, independent, and successful software.

When a minimal valuable product has been established successfully, everything has to go faster and the development team should be significantly enlarged! However, more developers usually reduce the productivity of the team. Communication is becoming much more complex and the willingness of developers to take responsibility is significantly decreasing! But how can the team now be meaningfully expanded?

With Domain-driven Design and Fluid Sub-Teams!

DDD enables the sustainable growth of teams without having to scale. However, this solution is not recognized by most companies. Using domains and sub-domains, the agile team can be divided into fewer complex sub-teams, which take on more responsibility and work more efficiently. Self-organization and joint Scrum events minimize the risk of dependencies.

Matthias Eschhold and Nils Hyoma explain how they built and established agile, scalable software architecture and team structures of up to 25 members in complex domains. The members took on more and more responsibility, the value, the quality, and even the speed of development increased significantly.

Nachhaltig Wachsen mit fluiden Teams und Domain-driven Design en de

Scrum ist das Framework für die Entwicklung von Softwaresystemen in komplexen und fast chaotischen Umgebungen. Durch geschicktes Product Ownership entstehen fachlich kompetente Entwicklungsteams. Cross-Funktional aufgestellt entwickeln sie hoch-produktiv, eigenverantwortlich und erfolgreich Software.

Ist ein Produkt erfolgreich gestartet, muss alles schneller gehen und das Entwicklungsteam soll deutlich vergrößert werden! Weitere Entwickler reduzieren jedoch meistens die Produktivität des Teams. Die Kommunikation wird deutlich komplexer und die Bereitschaft der Entwickler Verantwortung zu übernehmen nimmt signifikant ab! Doch wie kann das Team jetzt sinnvoll erweitert werden?

Mit Domain-driven Design und Fluiden Sub-Teams!

DDD ermöglicht ein nachhaltiges Wachstum von Teams, ohne skalieren zu müssen. Diese Lösung wird aber von den meisten Firmen nicht erkannt. Anhand von Domänen und Subdomänen kann sich das agile Team in weniger komplexe Sub-Teams aufteilen, diese übernehmen mehr Verantwortung und arbeiten effizienter. Durch Selbstorganisation und gemeinsame Scrum Events wird das Risiko von Abhängigkeiten minimiert.

Matthias Eschhold und Nils Hyoma erzählen, wie sie in komplexen Domänen skalierbare Softwarearchitektur und Teamstrukturen von bis zu 20 Mitgliedern aufgebaut und etabliert haben. Die Mitgliedern übernahmen immer mehr Verantwortung, der Wert, die Qualität und sogar die Entwicklungsgeschwindigkeit konnten deutlich gesteigert werden.

Domain Driven Rearchitecting mit dem "Domain-from-Legacy" Canvas de

Wartbarkeit ist ein abstrakter Begriff und selbst wenn man sich die Definition vor Augen führt, bleiben noch Fragen offen. Am besten kann Wartbarkeit verstanden werden, wenn die tägliche Arbeit davon betroffen ist und die bestehenden Systemstrukturen kein effektives Entwickeln von Software mehr zulässt. Manager und Entwickler kennen dieses Phänomen, dass aufgrund der fehlenden Wartbarkeit eine reduzierte Produktivität zu beobachten ist.

In diesem Vortrag zeige ich wie mit Domain-driven Design Softwaresysteme modernisiert werden können. Das zu Grunde liegende reale Beispiel zeigt eine Transformation von einer monolithischen, in technische Schichten organisierte Architektur, zu einer in Domänen strukturierten und fachlich ausdrucksstarken Anwendungsarchitektur. Die Restrukturierung und das Beseitigen der technischen Schulden, stellte die Produktivität der Entwicklungsteams wieder her. Das System wurde wieder wartbar auf Basis eines gemeinsames Verständnis für die Domäne und die Architektur.

Die entscheidenden Erfolgsfaktoren sind Kommunikation und Kollaboration zwischen allen Beteiligten! Das Domain-from-Legacy Canvas stellt Domain-driven Design und kollaborative Entwicklungsarbeit als Grundstein erfolgreicher Architekturmodernisierung in den Vordergrund und unterstützt den Modernisierungsprozess auf strategischer und taktischer Architekturebene. Durch ein Domänenmodell und einer Karte von Bounded Contexts entstehen Artefakte für effektive Kommunikation. Lassen Sie sich inspirieren von einem pragmatischen Ansatz der Architekturmodernisierung.

In diesem Vortrag zeige ich Ihnen, wie Sie mit Domain Driven Design Ihre Anwendungsarchitektur modernisieren können. Auf Basis von realen Beispielen diskutieren wir die wichtigsten Prinzipien und Muster und denken die bestehende Architektur neu. Methodisch unterstützt werden wir dabei durch das "Domain-from-Legacy"-Canvas.

Domain-driven Rearchitecting with the “Domain-from-legacy” Canvas en

What is maintainability? Most developers and product owners can't answer this question even after reading official definitions because they are too abstract. Do you wonder why the sprint goal hasn't been met over and over again? Do developers experience being less productive? Congratulations, your system is probably not maintainable. If you know this all too well and are wondering what can be done to improve the situation, Domain-driven Rearchitecting could be a suitable approach for you.
On the basis of real-life examples, I will demonstrate how you could improve your architecture by following principles and patterns of Domain-driven Design. We are focusing on using the “Domain-from-Legacy” canvas. This is a collaborative and incremental method for software architecture modernization. We will start with analyzing existing code to find potential independent functional units. Lastly, we investigate these units according to DDD principles. In the end, we finalize the socio-technical architecture of the future based on bounded contexts.
Get inspired by an agile and collaborative way to modernize your architecture and make your development team productive again.

On the basis of real-life examples, I will demonstrate how you could improve your architecture by following principles and patterns of Domain-driven Design. We are focusing on using the “Domain-from-Legacy” canvas. This is a collaborative and incremental method for software architecture modernization.

Spielerisch zur domänen-getriebenen Architektur: DDD mit Gamifaction enabeln de

Die Einführung von Domain-Driven Design (DDD) in Unternehmen stellt oft eine Herausforderung dar, da neues Wissen und neue Methoden im gesamten Team verankert werden müssen. Hier setzt unser Gamification-Ansatz an: Mit den "Domain-Driven Design Cards" haben wir ein spielerisches Format entwickelt, das die Prinzipien und Konzepte von DDD auf motivierende und kollaborative Weise vermittelt.

In meinem Vortrag stelle ich Ihnen die DDD Cards vor, die in Form von vier eigenständigen Spielen die wichtigsten Elemente des DDD-Prozesses unterstützen. Ob es darum geht, Bounded Contexts zu definieren, Abhängigkeiten zwischen Bounded Contexts zu gestalten, Subdomains zu klassifizieren oder Entscheidungen für die taktische Architekturebene kollaborativ zu treffen – diese Spiele fördern den Austausch, steigern das Verständnis und helfen, DDD in Teams nachhaltig zu etablieren. Durch die Kombination von Gamification und Methodik schaffen wir einen praxisnahen Lernprozess, der alle Teammitglieder gleichermaßen einbindet, unabhängig von ihrem Wissensstand.

Ich freue mich darauf, meine Visionen und Ideen mit Ihnen zu teilen und wertvolles Feedback aus der Community zu erhalten.

Clean Architecture as Code de en

"Neues ist immer besser!" - Das mag nicht jeder so sehen, doch meiner Meinung nach baut Neues oft auf Altem auf. Indem wir neue Ideen aufgreifen und identifizierte Schwächen beheben, stellt das Neue oft eine Verbesserung dar. Betrachten wir dies im Kontext von Architekturmuster, so ist die Entwicklung von der Schichtenarchitektur als De-facto-Standard hin zu Ports & Adapter-basierten Architekturmuster wie der Clean Architecture als neuen De-facto-Standard zu beobachten.

Dennoch ist es eine Herausforderung, diese Architekturmuster in eigenen Projekten anzuwenden. Der Aufbau des erforderlichen Know-hows parallel zum Tagesgeschäft kann eine beträchtliche Hürde darstellen. Hexagonal und Clean Architecture stehen zwar für Qualität und Flexibilität, beinhalten jedoch auch mehr Designregeln und -prinzipien im Vergleich zur Schichtenarchitektur. Dennoch kann schnell ein Verständnis für die Anwendung im Projekt aufgebaut werden.

In "Clean Architecture as Code" beschreibe ich die grundlegenden Konzepte des Clean Architecture Patterns anhand eines fachlichen Use Cases. Dabei verwende ich überwiegend Codebeispiele, angereichert mit möglichst wenig architektonischem Fachjargon. Dabei möchte ich aufzeigen, dass die Lernkurve eventuell gar nicht so hoch ist, wie oft vermutet, und zum Ausprobieren ermutigen.

Clean Architecture as Code de en

"New is always better!" - Not everyone may see it this way, but in my opinion, new often builds upon the old. By embracing new ideas and addressing identified weaknesses, the new often represents an improvement. When we consider this in the context of architectural patterns, the shift from the Layered Architecture as the de facto standard to Ports & Adapters-based architectural patterns like Clean Architecture can be observed as the new de facto standard.

Nevertheless, applying these architectural patterns in one's own projects is a challenge. Building the necessary know-how alongside daily operations can be a significant hurdle. While Hexagonal and Clean Architecture signify quality and flexibility, they also encompass more design rules and principles compared to the Layered Architecture. However, an understanding of their application in the project can be quickly developed.

In "Clean Architecture as Code," I describe the fundamental concepts of the Clean Architecture Pattern using a practical use case. I predominantly use code examples, enriched with as little architectural jargon as possible. My aim is to demonstrate that the learning curve may not be as steep as often presumed and to encourage experimentation.

Clean and Flexible Software Architecture de en

Flexible business models require flexible software architectures. If the software architecture optimally implements the needs of the business domain, decisive competitive advantages can be achieved. In addition to a domain-oriented software architecture, architecture patterns and principles are needed that support "Design for Change" and, further on, "Flexibility by Design".

The Clean Architecture Pattern promises a decoupling of the domain from infrastructural aspects. This is the basis for a flexible software architecture. The underlying idea of ports and adapters is powerful and helps to realise technical, domain-related and organisational flexibility in the application architecture.

In this talk you will get to know possible real-life flexibility requirements and the Clean Architecture Pattern for supporting "Flexibility by Design". You will gain an deep understanding and will be able to assess when the use of Clean Architecture Pattern is suitable for your problems and how you could realise it on the level of packages and classes. Using code examples in Java, we discuss advantages, disadvantages and compromises.

Bedeutet Clean auch Green? de

Nutzen Sie seit Jahren das Clean Architecture Pattern? Dann kennen Sie sicherlich dessen Vor- und Nachteile: Es sorgt für eine klare Struktur, erleichtert die Wartbarkeit und trennt Verantwortlichkeiten sauber voneinander. Die Vorteile sind wertvoll – und die Nachteile haben wir akzeptiert.
Doch haben Sie sich jemals gefragt, ob Clean Architecture auch ökologisch nachhaltig ist? Ist "Clean" also automatisch auch "Green"?
In unserem Vortrag gehen wir dieser spannenden Frage auf den Grund. Wir betrachten verschiedene Architekturebenen – von der Systemarchitektur über die Integrationsarchitektur bis hin zur Anwendungsarchitektur – und analysieren, welchen Einfluss Clean Architecture auf die Nachhaltigkeit von Software hat. Unsere Aussagen stützen wir auf konkrete Messungen und bieten praxisnahe Einblicke, wie eine durchdachte Softwarearchitektur zur ökologischen Nachhaltigkeit beitragen kann.