Hallo, in ruclips.net/user/liveKocFrzZt9h0?feature=shared Wird erwähnt, dass es sinnvoll ist bei der Entwickung von Architektur den dreiklang modul, team, geschäftsfunktionalität zu haben (8:45 bis 9:00 link) In diesem video 53:48 bis 54:00 ist es wichtig relevante Fragen zu stellen. Es geht um Teams und vorgehensweise solcher teams wenn diese gleichzeitig mehrere projekte besrbeiten müssen. ruclips.net/video/DArIsvDWvh4/видео.htmlfeature=shared Dieses video erwähnt einen Lösungsvorschlag über dev. Container. wie sinnvoll ist eine solche umsetzung für teams und welche nachteile gibt es? (Zeitstempel 4:27 bis 5:42 ) Ich freue mich auf eine antwort
Das sind zwei sehr unterschiedliche Ebenen. Ich kann sicher die Umgebung für die Arbeit an einem anderen Projekt technisch schnell wieder aufbauen. Aber das Problem ist dann dennoch, dass ich verstehen muss, was in dem anderen Code und in dem anderen Projekt Thema ist. Und das ist aufwändig. Ich finde ja die Metapher "Entwickeln=Lernen" gut. software-architektur.tv/2023/12/08/folge191.html Dann ist aber so ein fachlicher Kontext-Switch das Problem, nicht die Technik - und ich würde ihn versuchen zu vermeiden, weil das dann doch aufwändig ist.
Auch für Klassen gilt, dass sie eine lose Kopplung haben sollten. Eine wichtige Eigenschaft von Software-Systemen sind die Hierarchien: Systeme sind beispielsweise in Microservices aufgeteilt. Die wiederum beispielsweise in Java Packages und die in Klassen. Auf allen diesen Ebenen sollte es eine lose Kopplung geben. Und auf jeder dieser Ebene sind die Konzepte (Microservice, Package, Klasse) Module.
@16:04 Wieso wird angenommen, dass Bibliotheken voneinander abhängig sind? Man kann Bibliotheken völlig unabhängig bereitstellen/verwenden - als Web-Entwickler lade ich eine Bibliothek wie jQuery und danach oder davor bspw. völlig unabhänigig davon D3.js. Oder geht es darum, dass Bibliotheken voneinander abhängig sein KÖNNEN, Microservices aber nicht? Daher auch unverständlich die Aussage: "bei Bibliotheken muss ich das gemeinsam deployen".
In dem Beispiel geht es darum, dass man ein System in verschiedene Elemente aufteilt - beispielsweise eines zur Annahme von Bestellungen und eines zum Schreiben von Rechnungen. Rechnungen benötigen Informationen über Bestellungen, also gibt es dort eine Abhängigkeit. Wenn ich nun eine Library für das Entgegennehmen von Bestellungen baue und eine für das Schreiben von Rechnungen, werde ich sie in der Reihenfolge 1 - Annahme von Bestellung und 2 - Schreiben von Rechnungen bauen lassen. Dann kann ich sicher sein, dass 2 1 benutzen kann, aber nicht umgekehrt. Librarys können natürlich wie von Dir dargestellt unabhängig sein, gerade wenn sie wie in Deinem Beispiel technische und keine fachlichen Probleme lösen. Typischerweise wird man die Anwendung mit allen Librarys gemeinsam deployen. Aber ja, da könnte es Ausnahmen geben beispielsweise bei dynamischen Librarys. Guter Punkt. Vielleicht hätte ich präziser sagen sollen, dass man einzelne Librarys nicht zur Laufzeit auswechseln kann.
lesenswert: "Legacy-Software implementiert bereits eine Lösung für das Geschäftsproblem. Dadurch sind die Domäne und auch der Business Case bekannt, den die Legacy-Software bedient. Eine Architektur und ein Technologie-Stack, mit denen man das Problem lösen kann, sind auch bekannt, auch wenn nur ein suboptimaler Ansatz umgesetzt worden ist. Und vor allem die Domänenexpert:innen als Stakeholder des Systems und die Benutzer:innen des Systems sind bekannt. So bietet Legacy einen Wissensvorsprung," Geschäftsproblem, Domäne, Business Case, Architektur, Technologie Stack, Stärkeholder (Domänenexperten). Kannst du uns (der Community) bitte irgendwann die Freude machen das alles in einem Gesamtvideo darzustellen und die zusammenhänge? 😅😅
"Web Components" sollten bezüglich "Komponenten" erwähnt werden. Es gibt immer mehr Web Frameworks, die ihre eigenen Web Komponenten haben. Aber Frameworks kommen und gehen und verändern sich (Stichwort: Abhängigkeit). Mir gefällt der Ansatz bei den "Web Components", ein Standardkomponentenmodell für das Web bereitzustellen (welches Kapselung und Interoperabilität einzelner HTML-Elemente ermöglicht). Für mich ähnlich bedeutsam wie HTML selbst.
Hallo,
in
ruclips.net/user/liveKocFrzZt9h0?feature=shared
Wird erwähnt, dass es sinnvoll ist bei der Entwickung von Architektur den dreiklang modul, team, geschäftsfunktionalität zu haben (8:45 bis 9:00 link)
In diesem video 53:48 bis 54:00 ist es wichtig relevante Fragen zu stellen.
Es geht um Teams und vorgehensweise solcher teams wenn diese gleichzeitig mehrere projekte besrbeiten müssen.
ruclips.net/video/DArIsvDWvh4/видео.htmlfeature=shared
Dieses video erwähnt einen Lösungsvorschlag über dev. Container. wie sinnvoll ist eine solche umsetzung für teams und welche nachteile gibt es? (Zeitstempel 4:27 bis 5:42 )
Ich freue mich auf eine antwort
Das sind zwei sehr unterschiedliche Ebenen. Ich kann sicher die Umgebung für die Arbeit an einem anderen Projekt technisch schnell wieder aufbauen. Aber das Problem ist dann dennoch, dass ich verstehen muss, was in dem anderen Code und in dem anderen Projekt Thema ist. Und das ist aufwändig. Ich finde ja die Metapher "Entwickeln=Lernen" gut. software-architektur.tv/2023/12/08/folge191.html Dann ist aber so ein fachlicher Kontext-Switch das Problem, nicht die Technik - und ich würde ihn versuchen zu vermeiden, weil das dann doch aufwändig ist.
Danke. Ich kann an der Unconference "Software-Entwicklung und Menschen" leider nicht teilnehmen. Aufgezeichnet wird sie aber vermutlich nicht oder?
Nein, sie wird nicht aufgezeichnet. Sorry!
23:30 wie ein framework funktioniert: framework ruft den code auf.
Meine Frage: haben frameworks normalerweise konfigurationsfiles?
Ich würde es nicht ausschließen, aber im Mittelpunkt steht Code.
Man hat sehr oft eine valide enge Kopplung zwischen zwei oder mehreren Klassen, natürlich kann sich ein Modul über mehrere Klassen erstrecken.
Auch für Klassen gilt, dass sie eine lose Kopplung haben sollten. Eine wichtige Eigenschaft von Software-Systemen sind die Hierarchien: Systeme sind beispielsweise in Microservices aufgeteilt. Die wiederum beispielsweise in Java Packages und die in Klassen. Auf allen diesen Ebenen sollte es eine lose Kopplung geben. Und auf jeder dieser Ebene sind die Konzepte (Microservice, Package, Klasse) Module.
@16:04 Wieso wird angenommen, dass Bibliotheken voneinander abhängig sind? Man kann Bibliotheken völlig unabhängig bereitstellen/verwenden - als Web-Entwickler lade ich eine Bibliothek wie jQuery und danach oder davor bspw. völlig unabhänigig davon D3.js. Oder geht es darum, dass Bibliotheken voneinander abhängig sein KÖNNEN, Microservices aber nicht? Daher auch unverständlich die Aussage: "bei Bibliotheken muss ich das gemeinsam deployen".
In dem Beispiel geht es darum, dass man ein System in verschiedene Elemente aufteilt - beispielsweise eines zur Annahme von Bestellungen und eines zum Schreiben von Rechnungen. Rechnungen benötigen Informationen über Bestellungen, also gibt es dort eine Abhängigkeit. Wenn ich nun eine Library für das Entgegennehmen von Bestellungen baue und eine für das Schreiben von Rechnungen, werde ich sie in der Reihenfolge 1 - Annahme von Bestellung und 2 - Schreiben von Rechnungen bauen lassen. Dann kann ich sicher sein, dass 2 1 benutzen kann, aber nicht umgekehrt.
Librarys können natürlich wie von Dir dargestellt unabhängig sein, gerade wenn sie wie in Deinem Beispiel technische und keine fachlichen Probleme lösen.
Typischerweise wird man die Anwendung mit allen Librarys gemeinsam deployen. Aber ja, da könnte es Ausnahmen geben beispielsweise bei dynamischen Librarys. Guter Punkt. Vielleicht hätte ich präziser sagen sollen, dass man einzelne Librarys nicht zur Laufzeit auswechseln kann.
lesenswert:
"Legacy-Software implementiert bereits eine Lösung für das Geschäftsproblem. Dadurch sind die Domäne und auch der Business Case bekannt, den die Legacy-Software bedient. Eine Architektur und ein Technologie-Stack, mit denen man das Problem lösen kann, sind auch bekannt, auch wenn nur ein suboptimaler Ansatz umgesetzt worden ist. Und vor allem die Domänenexpert:innen als Stakeholder des Systems und die Benutzer:innen des Systems sind bekannt. So bietet Legacy einen Wissensvorsprung,"
Geschäftsproblem, Domäne, Business Case, Architektur, Technologie Stack, Stärkeholder (Domänenexperten).
Kannst du uns (der Community) bitte irgendwann die Freude machen das alles in einem Gesamtvideo darzustellen und die zusammenhänge? 😅😅
@@marcm3623 Danke für das nette Feedback! Hilft ruclips.net/video/XKadk07LcW8/видео.html ?
@@EberhardWolff nicht wie die Faust aufs Auge.
@@EberhardWolff eher abstrahiert von legacy und dann einmal mit und einmal ohne.
"Web Components" sollten bezüglich "Komponenten" erwähnt werden. Es gibt immer mehr Web Frameworks, die ihre eigenen Web Komponenten haben. Aber Frameworks kommen und gehen und verändern sich (Stichwort: Abhängigkeit). Mir gefällt der Ansatz bei den "Web Components", ein Standardkomponentenmodell für das Web bereitzustellen (welches Kapselung und Interoperabilität einzelner HTML-Elemente ermöglicht). Für mich ähnlich bedeutsam wie HTML selbst.
Ja, guter Punkt - danke für den Hinweis!