Software Architecture Lab (ArchiLab) von Prof. Dr. Stefan Bente und seinem Team am Cologne Institute for Digital Ecosystems (CIDE) der TH Köln. Alles rund um Spezifikation, Implementierung und Anwendung von modernen Software-Architekturen!
Warum lassen sie beim Integrationstest das spring framework nicht weg? Ich dachte im DDD ist das framework nur ein Detail und wird ganz zuletzt angeschlossen. Bei mir läuft das nur im UI-Test.
DDD sagt da eigentlich nichts zu - da geht es eher um einen sauberen fachlichen Schnitt. Spring Framework ist beim Testen einfach als Dependency Injection Container nötig, um sich die zustandslosen Services zu instanziieren. (Und für eine Reihe anderer Convenience-Aspekte auch ...). Möglicherweise kann man das (irgendwie) umgehen, aber dann würde man ja in den Tests einen anderen Weg gehen als im Produktivcode.
@@archilab Ja, aber der saubere Schnitt ist doch zwischen fachlicher Logik und Technologie. Ja, auf DI und JPA muss man im DDD verzichten. Aber dies macht die Tests eh nur langsam und halt der erste Satz. Also ich gehe kein anderen Weg im Produktivcode. Es gibt nur dann zusätzlich ein *Bean-Service welcher von *Aggregate abgeleitet ist und eine H2DB für die Tests. Damit laufen die IT's unabhängig von spring und sind sie wesentlich schneller. "Mocken" (ich glaube für mich wäre ein anderer Begriff angebracht) muss man nur das Senden der Registrierungsmail und das Erzeugen von PW-Hash's (md5 nutzt ich im Test). ATM hab ich 900 Tests (meist IT's) die in 30s auf einem i5-8th Gen laufen. Wobei bei für jeden Test die DB geleert wird. So macht Entwicklung Spaß. Ich glaube ich hab noch nie so angenehm gearbeitet. Vorher haben die EE frameworks immer ein wenig genervt oder ärger gemacht.
Super erklärt! Vielen Dank! Nur eine Stelle versteh ich nicht, nämlich die Begründung, warum POST keine "sichtbare Semantik" hat. Ich würde "sichtbare Semantik" so verstehen, dass die Bedeutung des Requests ersichtlich ist, und das ist sie doch bei einem POST, nämlich "Anlegen der benannten Ressource", oder nicht? Sie sagen da, dass man dafür in den Body reingucken müsste, aber inwiefern unterscheidet sich das von PUT/PATCH? Ich würde sagen der Unterschied zwischen POST und PUT/PATCH liegt in dem Kriterium "identifizierbare Ressource".
Wow, der erste Kommentar überhaupt? Dann ist ein "Vielen Dank für deine Mühe!" aber erst recht überfällig! Sehr hilfreich zum Verständnis von RestAPI-Abfragen.🤓
Moin @archilab, danke für eure tollen Videos! Eine Frage: Wenn ich als Anforderung die Historisierbarkeit von Änderungsdaten habe, sprecht ihr ja hier von der Modellierung und entsprechend Implementierung dieser. Nun könnte ich ja aber auch darauf verzichten und stattdessen auch auf Auditing der Stamm-/Bestandsdaten direkt auf der Datenbank setzen. Gibt es hier einen Vorteil durch die Modellierung? (Vermutlich gilt die Antwort dann auch für Bewegungsdaten?) Danke :)
Wenn ich das direkt in der Datenbank mache, dann binde ich Fachlogik an eine bestimmte Technologie (meine [vermutlich relationale] DB), und ich verteile mein Domain Model an zwei Stellen. Daher bin ich kein Fan von so einem Ansatz.
Endlich ein Vortrag, ohne sinnloses, nerviges, lautes Intro, kurz, klar, deutlich, übersichtlich und verständlich. Warum haben das nur so wenig Leute angesehen in dieser langen Zeit ?
Toller Kanal! Hilft mir sehr beim lernen und weiterbilden, sowie diese Konzepte letztlich zu verstehen und anzuwenden. Alles sehr verständlich. Vielen lieben Dank für Deine Videos!
Vielen Dank für das tolle Video. Wie gliedert sich denn die Domäne in die Projektorganisation oder Projektstruktur ein? Ist die Domäne das Kerntream eines Projektteams oder ersätzt die Domäne den Produktowner und gibt Anforderung und Aufträge direkt an die Entwickler weiter? Gibt es in dem Modell einen Projektleiter?
Das sind eher zwei verschiedene orthogonale Ebenen. Die Domäne ist fachlich getrieben. Wie man eine Projektstruktur dazu definiert, hängt von vielen Faktoren ab - unter anderem natürlich der Projektgröße; es kann natürlich Projekte geben, die mehrere Domänen überspannen. Daher ist es eher sinnvoll, in (agilen, selbstorganisierten) Teams zu denken. Diese Teams sollten sich innerhalb einer Domänen- oder Subdomänengrenze befinden, damit eben Diskussionen leichter werden.
Viele Dank für die hilfreiche Videoreihe! Kleine Anmerkung: "Im vergangenen Video" am Anfang trifft nicht zu, das vergangene Video ist "Eine kurze Einführung in Domain-Driven Design (DDD)". Welches ist das gemeinte Video?
@@archilab Vielen Dank! Ich erstelle gerade ein DDD Domänenmodell für ein Java Programm.. Welches Video würden Sie mir dazu empfehlen außer das über Entitäten und Value Objects? (die Begriffe sind bekannt). Viele Grüße, ein Student
@@HA-gu1qk Ich würde mir in jedem Fall die beiden Videos zu Aggregates anschauen. Darüber hinaus das zu Domain Primitives. Zum ganzen Strategic Design (Bounded Context etc.) fehlen leider (noch) Videos. Interessant könnte zusätzlich sein, sich die drei Videos zum Logischen Datenmodell anzuschauen, auch wenn das nicht nach DDD klingt. Es hilft aber IMHO sehr dabei, die Abhängigkeiten richtig zu modellieren (und in der richtigen Richtung). Also ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-wSXWknKQkbU.html, ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-RufBXPTt1SA.html und ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-w6967RWoLTk.html.
Der gute Evans hat 2005 Regeln aufgestellt die heute erst von der Mehrzahl verstanden werden und nach wie vor "best practice" sind ... eine Seltenheit in der IT - Welt
Guten Tag. Ich möchte Ihnen nur ein kleines Feedback geben und sagen, dass es super cool ist, dass Sie Ihr Wissen hier öffentlich teilen und dass Sie das sehr gut machen. Ich bin froh und dankbar, dass ich Zugang zu Ressourcen wie diesen habe, um mich auf meine zukünftige Karriere vorzubereiten. Ich beginne nächstes Jahr eine Ausbildung zum Fachinformatiker für Anwendungsentwicklung und dank solchen Vorträgen kann ich mir ein solides Fundament an Wissen aufbauen, um meine Karriere mit Zuversicht und Selbstvertrauen zu starten. Ich wünsche Ihnen alles Gute und weiterhin viel Erfolg!
Sehr cooles Video, gerne mehr davon! :D Ich finde Clean Code sollte man immer mit so praktsichen Beispielen erklären, so lernt man viel schneller und praktischer was. @25:30 Ich denke auch die grüne Variante ist riskant. Würden wir annehmen, dass auch das produkt.asMarkdown() stets einen Footer ergänzt, dann würde im getMarkdown() des Produktkatalogs für jedes Produkt der Footer injiziert werden. Vermutlich gehört der Footer semantisch gar nicht zum Markdown und eine völlig neue Funktion sollte das Markdown ergänzt mit dem Footer returnen. Hier würde das Problem dann auftreten, wenn ein Markdown aus mehreren Produktkatalogen erzeugt werden soll.
@@lars4953 Wenn Du meinst .. Ich bin IT Systemadmin und arbeite fast nur auf dem Terminal .. Es ist alles eine Sache der Gewöhnung - und übersichtlich ist es auf dem Terminal auch
Hi, muss man wissen was die Domäne ist um Microservices machen zu können oder abzuleiten zu können? ist Login und Registration und Registration Mail senden eine Domäne und somit Kandidaten für Microservices?
Das scheint eine klassische Generic Subdomain zu sein, siehe github.com/ddd-crew/core-domain-charts. Ob man daraus einen Service macht oder z.B. das Sidecar-Pattern, wäre eine andere Frage. Hier böte sich sicher Keycloak an.
