Taktische Softwarearchitektur

"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).

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,

• zu reflektieren, wo und warum die DDD-Praktiken anwenden solltest
• die grundlegenden DDD-Building Blocks zu erkennen und zu verwenden
• Anwendungen mit sauberem Layering zu implementieren und einige Best Practices zu erkennen
• die Beziehung zwischen Namespaces, Modulen, Aggregaten und Bounded Contexts zu diskutieren
• dir der typischen "Smells" bewusst zu sein