Get in touch
"Die Implementierung von Software ist schon schwierig genug, aber wie können wir ohne fundiertes Domänenwissen hoffen, dass sie überhaupt Sinn ergibt?" (Eric Evans)
Bei einem Softwareentwicklungsprojekt ist es für Entwickler:innen von entscheidender Bedeutung, die Problemdomäne zu verstehen, um sie in einem verständlichen und leistungsfähigen Domänenmodell in der Software abstrahieren zu können. Daher müssen Entwickler:innen, Domänenexpert:innen und Anwender:innen eine gemeinsame Sprache sprechen: Dies sind die Grundgedanken von Domain-Driven Design (DDD). Im Idealfall wird der Code an der Realität des Problems ausgerichtet, hierzu werden Gespräche mit Anwender:innen und Fachleuten durchgeführt. Die Verwendung bestimmter Bausteine und eine gut getrennte Schichtung in der Software ist der Schlüssel zu einem wartbaren und verständlichen Code. Außerdem: Während neue Entwickler:innen den Code verstehen, verstehen sie gleichzeitig auch den Problembereich (und dessen Abstraktion).
Unser nächstes Domain-driven Design-Training findet am 9. Oktober 2024 statt.
Domain-Driven Design – Motivation
Domain-Driven Design ist eine Familie von Software- und Architekturmustern und Best Practices. Es ist aber auch ein Prozess, der den Code an der Realität der Problemdomäne ausrichtet und Entwickler:innen und Domänenexpert:innen zusammenarbeiten lässt. DDD hat sich als sehr hilfreich erwiesen, wenn man wartbare Software für einen Problembereich schreiben will, der eine gewisse Komplexität aufweist. Wenn du also Software entwickeln musst, die für dein Unternehmen strategisch relevant ist – und sich wahrscheinlich im Laufe der Zeit ändern und weiterentwickeln wird – solltest du mit den Ideen und "Building Blocks" des Domain-Driven Design vertraut sein.
Eine Software, die eng an der realen Problemdomäne modelliert ist, lässt sich viel leichter erweitern und anpassen: Die Schwierigkeit, neue Funktionen hinzuzufügen, bleibt nämlich konstant relativ gering. Und wenn die Lösung ordnungsgemäß entlang von Bounded Context-Lines aufgeteilt ist, ist es ein Leichtes, Teile davon in Microservices zu extrahieren.
Domain-Driven Design geht Hand in Hand mit "Clean Code" und hexagonalen Architekturen. In unseren praxisnahen Trainings integrieren wir diese Ansätze und unsere Erfahrungen aus echten Enterprise-Projekten. Darüber hinaus erhöht DDD die Sicherheit (Security by Design) und die Testbarkeit deiner Software um ein Vielfaches.
Trainingsziele und -konzepte
Das Training beginnt mit einer Reflexion über allgemeine Herausforderungen in der Softwareentwicklung und darüber, wo DDD-Praktiken geeignet sind, um diese Herausforderungen anzugehen.
Dann geben wir einen Überblick über taktische DDD-Building Blocks und -Patterns und vermitteln Know-how für die praktische Umsetzung. Damit du dem Training gut folgen kannst, verwenden wir eine Beispieldomäne, der wir Schritt für Schritt nachgehen und diskutieren Codebeispiele aus der Praxis (in Golang).
Nach dem Training bist du in der Lage,
1. Einführung in DDD
2. Vorstellung der Beispieldomäne "Hackerando"
3. Anwendungsarchitektur: Vorteile eines "technologiefreien Domänenmodells", Trennung von Belangen und typischen Schichten, Konzept von Ports und Adaptern
4. Überblick über taktische Patterns und Building Blocks
5. Design Patterns
6. Implementierung von DDD
Für eine Einführung in strategische Muster der Softwareentwicklung/-architektur besuche bitte auch das Training "Strategische Softwarearchitektur" (in keiner bestimmten Reihenfolge)
Daniel Pötzinger verfügt über langjährige Erfahrung in der Entwicklung und Architektur von Enterprise Web Applications. Er hat mit vielen großartigen selbst-organisierten Agile-Teams zusammengearbeitet und weiß, wie Zusammenarbeit und gegenseitige Inspiration – zusammen mit den richtigen Technologien und Patterns – Softwareprojekte zum Erfolg führen und das Lösen von Herausforderungen zum Vergnügen machen können. Außerdem verfügt Daniel über umfassendes Wissen darüber, wie man DevOps und Continuous Delivery Praktiken in IT-Organisationen einführt.
Bei AOE stellt Daniel sein umfangreiches Beratungs-Know-how zur Verfügung und hat mittlerweile mehr als 100 Enterprise-Projekte für Kunden wie Deutsche Telekom, congstar, Rovio und Cisco Webex begleitet. Darüber hinaus betreut er weiterhin die Entwicklung von AOE Produkten wie Searchperience, einer hochentwickelten Enterprise-Such- und Recommendation-Engine und Flamingo, einem skalierbaren Frontend-Framework für Headless Microservice-Architekturen und moderne Commerce-Anwendungen.
Stefan Rotsch verfügt über langjährige Expertise in der Entwicklung und Architektur komplexer Webapplikationen. Als Solution Architect bei AOE GmbH analysiert und entwirft er Softwareprojekte im Telekommunikationsbereich und begleitet Kund:innen und Entwicklungsteams von der Konzeption bis zum erfolgreichen Go-Live. Er teilt seine Erfahrungen im Bereich der agilen Softwareentwicklung mit großem Erfolg in diversen Vorträgen auf Konferenzen und Bar Camps.