Effiziente Komplexitätsreduktion in der skalierenden Produktentwicklung mit Domain-Driven Design

In unserer praxisnahen Präsentation nehmen uns Mathias Eschhold (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 Stakeholder:innen und Entwickler:innen.

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.

KEY TAKEAWAYS:
- Einführung in Domain-Driven Design - fachliches Backlog Management für mehrere Teams unterstützt durch Domain-Driven Design - Methoden Co-Creation in großen Gruppen - praktische Strategien zur Koordination von Teams in Interaktionen
ZIELGRUPPE:
Agile Coaches
Product Owner:innen

Links:
- https://github.com/MatthiasEschhold/domain-driven-design-cards
- https://www.etsy.com/de/shop/AgileGames

Transcript

1. Effiziente Komplexitätsreduktion in der skalierenden Produktentwicklung mit Domain-Driven Design Matthias Eschhold und Nils Hyoma Scaling Agile Summit 2024
2. Matthias Eschhold • EnBW AG • Lead Architect Business Domäne E-Mobilität • Trainer für Softwarearchitektur Foundation, Domain-Driven Design und Clean Architecture
3. Nils Hyoma • Manager bei MHP – A Porsche Company • RTE für Fuhrpark Software • Ehemaliger Developer
4. • Es gibt fachliche Missverständnisse und Kommunikationsprobleme • Schwierige Koordination zwischen Teams • Starr und unflexible Architektur • Ineffektive Abstimmung mit Stakeholdern • Schwierigkeiten bei Wiederverwendbarkeit und Modularität • Das Team übernimmt keine Verantwortung Herausforderungen in der skalierenden Produktentwicklung
5. Big Ball of Mud • Unstrukturierter Code • Schlechte Wartbarkeit • Hohe Komplexität • Mangelnde Dokumentation • Technische Schulden • Entwicklerabhängigkeit
6. Big Ball of Mud
7. Einführung in Domain-Driven Design • Fokus auf das Verständnis der Domäne • Verwendung einer gemeinsamen Sprache (Ubiquitous Language) • Strategisches und Taktisches Design • Vorteile: • Verbesserte Kommunikation und Zusammenarbeit • Klarere Architektur und Struktur • Bessere Anpassungsfähigkeit und Wartbarkeit
8. Findet sich wieder im: • Glossare • Domain Storytelling Maps • Moddellierung • Code Ubiquitous Language in Domain-Driven Design
9. Anti-Pattern mehrdeutige Modelle Fahrzeug ID Fahrzeugmodell Fahrzeugtyp Kennzeichen Kilometerstand Name Vorname Anlagedatum 12345 Porsche 911 2022 2.0 HH-ST-1910 8000 Hyoma Nils 13.12.2022 12346 3er BMW E90 S-VK-1899 693442 Eschhold Matthias 01.01.2023 12347 Trabbi 1989 B-EH-1989 5 Maul Ronny 15.01.1887
10. Bounded Contexts Ein Bounded Context ist die Grenze um die Bedeutung eines fachlichen Modells! Klare Abgrenzung von fachlichen Fähigkeiten und deren Verantwortlichkeiten zur IT-Organisation einer (Business) Domäne Vorteile: Erhöhte Klarheit und Verantwortlichkeit • Reduzierung der Komplexität • Bessere Skalierbarkeit
11. Strategisches Design • Bounded Contexts • Context Maps • Ubiquitous Language • Klassifikation: Core, Supporting und Generic Domains
12. • Entities • Value Objects • Aggregates • Repositories • Services • Factories • Modules Taktisches Design
13. Was brauchen Architekten von Leadern in skalierenden Frameworks?
14. Wie mit Domain-Driven Design anfangen?
15. Fragen und Antworten
16. Danke