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
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?
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.
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.
Meiner Meinung nach sollte man technische Aspekte aus der Fachlichkeit so gut es geht verbergen. Deshalb gibt es ja den Domain-Layer. Dieser sollte von der Persistenz, Infrakstruktur, UI so weit entkoppelt sein, dass genau diese technologischen Aspekte nicht mit den fachlichen Aspekte vermischt werden.
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.
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
Ich könnte nicht mehr zustimmen! Wirklich, wirklich gut!!
Unbedingt mal Domain Modeling made Functional von Scott Wlashin lesen. DDD ist da sehr gut erklärt. Egal, ob man FP mag oder nicht.
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?
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.
Das hat aber nicht wirklich was mit DDD zu tun. Eher allgemein mit inkompetenten Managern oder generell inkompetentem Umfeld
@@gzoechiJa, das stimmt um so mehr schade.
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.
Meiner Meinung nach sollte man technische Aspekte aus der Fachlichkeit so gut es geht verbergen. Deshalb gibt es ja den Domain-Layer. Dieser sollte von der Persistenz, Infrakstruktur, UI so weit entkoppelt sein, dass genau diese technologischen Aspekte nicht mit den fachlichen Aspekte vermischt werden.
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.