Die 5 größten Probleme von Domain-Driven Design (DDD) // deutsch

Domain-Driven Design (DDD) gilt Vielen als zu abstrakt und zu akademisch. Zugegebenermaßen fällt der Zugang tatsächlich häufig sehr schwer, was nicht zuletzt daran liegt, dass es kaum empfehlenswerte Literatur zu dem Thema gibt.

Doch nicht DDD an sich ist das Problem, sondern die Art, wie es in der Regel vermittelt wird: Denn tatsächlich kann DDD durchaus anschaulich und greifbar vermittelt werden – es passiert nur viel zu selten!

In diesem Video stelle ich 5 Gründe vor, warum Domain-Driven Design (DDD) seit über 20 Jahren nicht so richtig aus dem Quark kommt, woran es hängt, und was dem Mainstream-Erfolg im Weg steht. Falls Du Dich auch immer schon gewundert hast, warum DDD so wenig verbreitet ist, wo es doch (angeblich) so toll sei: In diesem Video erfährst Du es!

Und wenn Du oder Dein Team das Gefühl haben, dass es eine gute Idee wäre, sich bezüglich Domain-Driven Design (DDD) einmal zusammenzusetzen, sei es für eine einführende Schulung oder auch für eine konkrete Modellierung, dann melde Dich bei uns:

────────────────────

Willst Du wissen, welche Videos es noch von uns gibt oder suchst Du eines zu einem bestimmten Thema? Hier findest Du die perfekte Übersicht über alle unsere Videos:

────────────────────

Möchtest Du demnächst den Job wechseln, hast aber Angst vor den technischen Fragen im Bewerbungsgespräch? Wir können Dir helfen! Werde Mitglied in unserem Coding-Circle und erhalte jede Woche exklusive Videos:

────────────────────

Hast Du Fragen zu diesem Video oder willst Du Dich mit Gleichgesinnten aus der Community austauschen? Dann komm auf unseren Discord-Server:

────────────────────

00:00 – Einleitung
01:39 – Problem #1: Zielsetzung vs Zielgruppe
04:30 – Problem #2: Wie der Einstieg (nicht) gelingt
06:09 – Problem #3: Patterns vs Konzepte
07:52 – Problem #4: Community: Zu elitär?
09:55 – Problem #5: Die Relevanz von DDD
10:57 – Warum man sich trotzdem mit DDD befassen sollte

────────────────────

[TheJaegerfeld]

Wunderbar zusammengefasst, ich versuche seit Jahren DDD bei Firmen umzusetzen und kann dir nur zusprechen.
Wir müssen anfangen genau darüber zu sprechen. Danke für das Video

[ThePerin]

Ich könnte nicht mehr zustimmen! Wirklich, wirklich gut!!

[mavsascha]

Mein Problem mit DDD ist immer der fehlende Kontakt zu Personen die die fachliche Seite kennen, im Regelfall habe ich immer eine Person, die alles vorzukauen versucht evtl. auch mehrere solche Personen hintereinander.

[karlgustav]

Mein Problem mit DDD: obwohl man eigentlich versucht Kontexte nicht zu vermischen, werden der fachliche und der Engineering- Kontext vermischt. Das führt zu ähnlichen Problemen wie wenn im Frontend UI Logik mit Business Logik vermischt werden (passiert in MVVM ähnlichen Architekturen/Frmaworks wie z.B. React sehr schnell) weil es vermeintlich einfacher ist. Aus Produktentwicklungssicht passiert es bei größeren Anwendungen (Produkte sind nicht nur Software) schnell, dass Features und Komponenten (Das eine ist Scope, das andere Software) gleich heißen, was schnell zu Verwirrung und Verrenkungen beim Vertrieb „Die Komponente XY lässt sich nicht verkaufen, an welchem Feature arbeitet ihr denn jetzt gerade?“ Außerdem führt es schnell zu Stilblüten, wenn versucht wird die Domäne möglichst wirklichkeitsnah umzusetzen. Das ist (außer wenn man eine Computersimulation programmiert) nicht die Aufgabe von Software. Der große Vorteil ist Abstraktion, nicht Realitätsnähe. Ich bin dafür eine Triade aus Scope (Features und Subfeatures) , Code (Komponenten und Methoden/Funktionen) und Work (Epics und Stories) zu nutzen, damit die Frage „Wer arbeitet woran, warum und worauf hat es Einfluss“ möglichst präzise beantwortet werden kann.

Aus meiner Sicht für kleine und mittlere Projekte gut geeignet, für große skalierbare Branchenlösungen leider eher weniger.

[pdqxhix]

Sehr gutes Video. Ich nehme auch eine - in viel zu großen Umfang - Abgehobenheit der DDD Community war.
Ich habe eine Frage zu einer Aussage bzgl. der Verbreitung in der IT Branche. Gibt es das irgendwas, womit Du das belegen kannst. Etwas das Du verlinken kannst?

[matthiasendler]

Also hochnäsige Leute haben sowieso ein Problem, denn sie nehmen sich selber das Potenzial zu wachsen. Ein weiteres gutes Buch ist Domain Modeling made Functional von Scott Wlaschin.

[a.r.s.]

Problem #6: An jede grössere IT Architektur wird DDD geschrieben und alle sind von dem anschliessend entwickelten Monolithen bestehend aus Microservices enttâuscht.
Problem #7: Für das Tayloring der Fachlichkeit und Design von Domainen gibt es viel zu wenig praktische Beispiele.
Problem #8: DDD wird von den Technikern designt und von den Business Analysten nicht verstanden.
Problem #9: Es gibt bei DDD einfach kein sauberes Vorgehen, mit sich überlagernden Datenqellen sauber umzugehen.
Problem 10#: Es gibt keine vernüftigen deutschen Wörter, die alle Stakeholder verstehen.
Fazit, DDD wird in dem Keller bleiben, in dem es steckt.