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.

Refactoring mit Stil: Clean Architecture Patterns für taktische Architekturverbesserung de

Schnelllebige Geschäftsmodelle erfordern flexible und rasch anpassbare Architekturen. Wenn die Softwarearchitektur optimal auf die Anforderungen der fachlichen Domäne abgestimmt ist, kann dies dazu beitragen, Wettbewerbsvorteile zu erzielen. Doch was passiert, wenn die Architektur weder erweiterbar noch wartbar ist und das Geschäftsmodell nicht unterstützen kann? In einem solchen Fall handelt es sich wahrscheinlich um einen "Big Ball of Mud", und es ist an der Zeit, das System zu modernisieren. Nur so können die zukünftigen Anforderungen des Geschäftsmodells erfüllt werden. Allerdings ist dies ein anspruchsvolles Unterfangen. Refactorings dieser Größe und Qualität erfordern nicht nur die Umsetzung der Refactoring-Maßnahmen selbst, sondern auch ein gemeinsames Verständnis für die Herausforderungen sowie die Architekturkonzepte zur Lösung derselben.

Im Rahmen der konzeptionellen Neuordnung des "Big Ball of Mud" besteht die Herausforderung darin, die Codestrukturen in das Clean Architecture Pattern zu überführen. Kann das Clean Architecture Pattern als Vision und Leitfaden für umfangreiche Architekturumbauten dienen und ein unterstützendes Werkzeug für Entwicklungsteams bereitstellen? Diese Frage möchte ich gerne mit Ihnen diskutieren.

Die Macht des gesprochenen Wortes: Domänenmodelle, Mustersprachen und andere sprachliche Auswüchse de

Die meisten digitalen Geschäftsmodelle sind fachlich und technologisch komplex. Ein großer Apparat von Personen verteilt auf Teams treiben das Geschäftsmodell voran. Agile Methoden und Ansätze zur Organisation von Teams, wie z.B. Team Topolologies oder SAFe, bilden das organisatorische Fundament der Business Domäne. Domain Driven Design ergänzt dies als Ansatz zur Gestaltung sozio-technischer, strategische und taktische Architektur. Das klingt nach einer modernen Ausrichtung der Softwareentwicklung. Klingt super, doch all das muss erstmal verstanden, angewendet und etabliert werden. Aller Anfang ist schwer und alles bedingt Kommunikation, Interaktion und stellenweise tiefgehende Kollaboration zwischen Personen und Teams. Die Qualität und Wirksamkeit der Kommunikation ist folglich ein Grundelement des Geschäftserfolg.

Domain-Driven Design stellt die Fachsprache in den Vordergrund. Dies wird erweitert durch Mustersprachen für System- und Teambeziehungen sowie für das Software Design. Ergänzungen für Softwarearchitektur runden das Sprachpaket ab, welches einer Business Domäne den richtigen Antrieb geben kann. Mein Vortrag stellt die Bedeutung von Kommunikation und Sprachmodellen ins Rampenlicht. Erfahrung aus unterschiedlichen Projekten und die dort erlebten Erfolge, Misserfolge und Lessons Learned möchte ich mit euch teilen.

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

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.

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

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.

Erfolg entsteht nicht im Scheinwerferlicht: Architecture Enabling (Anti-) Patterns de en

Erfolgreiche digitale Produkte entstehen durch fokussierte Entwicklungsteams, die auf einen kontinuierlichen Wertefluss ausgerichtet sind. Skelton und Pais bezeichnen dies als Stream-Aligned Team. Stream-Aligned Teams arbeiten ständig unter Zeitdruck und sind vergleichbar mit Schlüsselspielern wie dem Spielmacher und den Stürmern im Fußball, die den Erfolg repräsentieren.

Wenn ein Team scheitert, liegt das selten an mangelnder Motivation. Die Ursachen finden sich eher in entscheidenden Schwächen in der Gesamtorganisation sowie in den Herausforderungen und der Komplexität der Domäne. Hier kommen Enabler- und Platform-Teams als zusätzliche Teamtypen ins Spiel. Enabler-Teams übernehmen die Rolle eines "Sechsers" im Hintergrund und unterstützen Stream-Aligned Teams dabei, regelmäßig erfolgreich zu sein.

Komplexe und umfangreiche Domänen entstehen durch die Zusammenarbeit von verschiedenen Teams. Neben der strategischen Softwarearchitektur entwickelt sich bewusst oder unbewusst auch eine sozio-technische Architektur zwischen den Teams. Domain Driven Design und Team Topologies bieten Ansätze, um diese sozio-technische Architektur zu gestalten. Dabei konzentrieren wir uns auf das Konzept des Softwarearchitektur-Enabling. Wir werden untersuchen, wie ein Enabler-Team in einer Domäne etabliert werden kann. Ich habe an der Entwicklung verschiedener (Anti-) Patterns mitgewirkt und möchte gerne meine Perspektiven mit Ihnen teilen.

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.

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.

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.

Architecture Enabling (Anti-) Patterns de en

Successful digital products are created by development teams that are focused and aligned on a steady flow of value. Skeleton and Pais refer to this type of team as a stream-aligned team. Stream-aligned teams have the deadline permanently on their backs and are - like the playmaker and the strikers in soccer - the face of success!

If a team loses, it is rarely due to motivation. Rather, the causes can be found in decisive weaknesses in the overall organization as well as due to the challenges and complexity of the domain. This is where enabler and platform teams come into play as additional team types. Enablers take over the role of the "six-man" in the background and help stream-aligned teams to success!

Complex and large domains emerge from a federation of collaborating teams. In addition to the strategic software architecture, a socio-technical architecture between these teams emerges. Domain-Driven Design and Team Topologies describes possibilities to design such complex socio-technical systems. We focus on the idea of enabling using software architecture as an example. We explore how an enabler team can be established in a business domain. I have already participated in the design of different (anti) patterns and would like to share my experiences with you.

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.