Architektur ist überbewertet // deutsch

[@thenativeweb]

Du möchtest das Video an jemanden weiterleiten, die oder der aber lieber liest? Dann findest Du den passenden Artikel zum Video bei Heise Developer: www.heise.de/blog/Architektur-ist-ueberbewertet-und-was-wir-daraus-lernen-koennen-10191624.html

[@marcotroster8247]

Vielen Dank. Ich stimme größtenteils zu. Neben niedriger Kopplung und hoher Kohäsion ist der wichtigste Aspekt einer guten Architektur, dass die "Soft"-ware änderbar bleibt, sonst hat man nämlich "Hardware" entwickelt, die keiner anfassen will. Solange man das System flexibel hält, kann man die Designfehler, die man beim Lernen der Domäne unweigerlich machen wird, nachträglich wieder ausbügeln. Die Flexibilität vergessen die meisten Entwickler bei ihren Designs aber leider, was dann zu den typischen Problemen führt, bis hin zum kompletten Rewrite, weil keiner mehr durchblickt.

[@ReneHartmann]

In der Tat. Die Qualität einer Architektur bemisst sich daran, wie aufwändig und wie fehlerträchtig Änderungen sind. Alles andere ist bloß Gelaber.

[@ProggingTroll]

Microservices nur durch die Brille fachliche Kopplung und Kohäsion zu betrachten, ist, denke ich schwierig. Man bekommt dadurch zwangsläufig auch ernorme technische Komplexität. Auf einmal muss ich mit Aufrufen über Netzwerke arbeiten, mir um Konsistenz, Saga, Kompensation, Transaktionen, Choreographie oder Orchestriertung Gedanken machen. Ich habe auf einmal auch zusätzliche Infrastrukturlast, weil ich mir um Oberservability, Metriken, Tracing, Containerisierung, Betrieb eines Clusters etc. Gedanken machen muss. Ich brauche also DevOps Spezialisten, die sich damit auskennen. Daneben kommen organisatorische Frage: wie organisiere ich meine Repositories? Wie gehe ich mit Versionierung der Services um? Auf einmal mocke ich keine Db mehr, sondern ganze Services. Habe ich ggf. so Deployment Abhängigkeiten? Das sind die Themen, die ich bei Kunden sehe, die blind Trends nachlaufen und meinen, alles muss jetzt mit Microservices gelöst werden. Daher habe ich viel Verständnis für Berater, die die klassische 3 Layer Architecture empfehlen als Modulith. Tatsächlich ist das für die meisten Anwendungen, die einem im Business begegnen auch ausreichend

[@marcotroster8247]

@@ProggingTroll Ja, man kauft sich einen Haufen Komplexität ein. Und vor allem kann man die Grenzen zwischen den Microservices nicht mehr so ohne weiteres verschieben. Wenn man nicht das Problem hat, dass hunderte Entwickler gleichzeitig an einem System Änderungen vornehmen müssen, sollte man eher die Finger davon lassen.

[@StephanHoyer]

Großartiges Video! Ich hab das ganze Dilemma noch nie so gut dargestellt gesehen. Respekt.

[@thorstenhirsch]

Sorry Golo, aber bei Microservices geht es nicht um geringe Kopplung und hohe Kohäsion (im Code), denn Module mit geringer Kopplung und hoher Kohäsion haben Entwickler schon sehr viel länger gebaut als es Microservices gibt. Auch bei Monolithen geht das. Bei Microservices sind die Module jedoch beim Deployment und zur Laufzeit getrennt, das macht sie aus. Ansonsten aber wieder sehr informatives Video, bitte weiter so!

[@ScriptRaccoon]

Gemeint ist eine geringe Kopplung auf einem höheren Level. Und da hat Golo schon recht. Die Komponenten selbst weisen in der gesamten Architektur weniger Kopplung auf.

[@LA-fb9bf]

​@@ScriptRaccoon du hast aber bei microservices wiederum mehr orchestrieraufwand. Komplexität steigt damit zusätzlich an.

[@clumsyjester459]

@@ScriptRaccoon Wieso haben deine Microservices, die sich per remote procedure call gegenseitig aufrufen, weniger Kopplung, als meine Module mit gut gebautem Interface?

[@sephirot7581]

@@clumsyjester459 Raccoon hat doch extra gesagt, dass ganze ist auf einer höhere Ebene gemeint: Prozesse, Deployment, Technologiewahl, Repository und so weiter Außerdem ist RPC nicht die einzige Möglichkeit zu kommunizieren

[@StephanRoth]

Microservices löst ein Organisationsproblem: Wie kann ich mit vielen verteilten Teams eine sehr große und komplexe Anwendung entwickeln, ohne dass sich diese vielen Leute permanent absprechen und abstimmen müssen, was 80% derer Arbeitszeit verschlingen würde.

[@linux912]

Du triffst es mal wieder auf den Punkt, im übrigen dehne ich das mal auf den IT Bereich aus ..

[@fraenkiboii]

Fast alles was Du sagst, trifft eiskalt auf mein Unternehmen zu und stößt mir eigentlich schon sauer auf, seit ich vor 14 Jahren anfing. "Die Architekten" ist ein Kreis Heiliger, die auf dem Elfenbeinturm sitzen und fachlich eigentlich keine Ahnung haben und meistens einfach nur extrem überzeugend und laut sind und deshalb von anderen gehört und respektiert werden. meistens haben diese Heiligen gar keinen Informatik bzw. SW-Engineering Hintergrund, sondern sind einfach nur dort, weil sie auch organisatorische Führungskraft sind. Es geht mir ganz direkt gesagt tierisch auf den Sack. Wenn dann einer der Heiligen eine Offenbarung hat und ein neues Framework gefunden hat, das als heil'ger Gral der Architektur gehyped wird, dann wird eine neue Sau durchs Dorf getrieben, ohne wirklich fachliche Anforderungen oder irgendeine andere Begründung aus Sicht der Architektur dafür zu haben.

[@Bobbel888]

Jede Domäne hält sich für heiliger als das Projektziel.

[@thorstenhirsch]

Zwingt die Architekten mit zu entwickeln!

[@ScriptRaccoon]

Gemischte Gefühle bei dem Video. Einerseits hast du damit Recht, dass es viele Architektur-Prinzipien gibt, die uns nicht bei der Software Entwicklung konkret helfen. Aber du hast in dem Zusammenhang auch einige Strohmänner gebracht wie "Architektur bekommt etwas magisches, nur die Elite kann das", "Architektur = Clean Code", "Du hast Uncle Bob beleidigt", und "Architektur wird Selbstzweck". Und in der zweiten Hälfte des Videos hast du doch ganz konkret erklärt, warum Software Architektur wichtig ist, und welche Aspekte dabei genau eine Rolle spielen. Mit anderen Worten: der Titel ist tatsächlich Clickbait und entspricht nicht dem Inhalt des Videos. Wie wäre es mit "Worauf es bei Software Architektur wirklich ankommt"?

[@m13v2]

hat er gesagt: coupling & cohesion! 🙂

[@suikast420]

12:28 Testcontainers

[@dennisbrieske8051]

Danke Golo! Wieder einmal ein gelungenes Video 👍 für jedes „Netflix“ in deinem Beitrag *die Tassen hoch* und der Abend wird bunt 😅 … Spaß beiseite. Ich gehe 100% konform mit deinen Aussagen. 👍

[@thenativeweb]

Ja, irgendwann während der Aufnahme ist uns auch aufgefallen, dass das Wort "Netflix" sehr häufig vorkam 🤣

[@Trv3GuY]

Ich gehe beim grundsätzlichen Punkt des Videos mit (wobei ich solchen Cargo Cult selber zum Glück noch nicht erlebt habe), allerdings gibt es zwei Punkte auf die ich gerne eingehen würde. Punkt 1: Ich find Architektur mit Strukturierung gleichzusetzen zu kurz gedacht. Ich find die Definition von Eberhard Wolff (zumindest glaube ich, dass sie von ihm kommt) hilfreicher: Architektur ist die Menge aller Entscheidung zur Umsetzung der fachlichen Anforderungen und Qualitätsanforderungen. Wie ich z.B. High Availability hinkriege ist keine Frage der Strukturierung, aber ich denke die meisten Leute würden zustimmen, dass es eine Architekturentscheidung ist. Punkt 2: Du hast im Vorbeilaufen Mocks als schlechte Idee bezeichnet. Ich finde Mocks durchaus nützlich, allerdings nur im richtigen Kontext. Nun bin ich durchaus interessiert was deiner Meinung nach die bessere Alternative zu Mocks ist. Vielleicht auch eine gute Idee für ein Video. Liebe Grüße!

[@StefaNoneD]

Punkt 2: Meiner Ansicht nach, gibt es keine gute Alternative zu Mocks, sondern nur Ergänzungen! Es gibt verschiedene Arten deine Software zu testen und für jede Ebene, gibt es geeignete Test-Möglichkeiten. Ich war über die Kritik bzgl. Mocks sehr überrascht, weil mein Team und ich damit gute Erfahrungen gemacht haben. Gerade, wenn man Hardware und Kommunikation simuliert, ist es sehr wertvoll.

[@valeridause]

Ich hatte Architekten erlebt, die ihre Vorstellung der System-Landschaft und der Prozess-Abläufe in Form von BPMN vor mehr als 250 Menschen vorgestellt hatten. Und für alle diese Diagramme waren wie Magie, sehr komplex und muss nur die klugen Sachen sein. Der Witz war aber, dass diese Diagramme vollkommen fehlerhaft waren und niemals es funktionieren würde. Daher. Architekt im Titel zu haben und Architekt zu sein - sie zwei unterschiedlichen Sachen. Wie in jedem Handwerk eben. Es wird nicht nur die Architektur, sondern auch die Job-Bezeichnung überbewertet. Danke für das Video!

[@Foreversun33]

Warum waren die Diagramme fehlerhaft? Es kann tausend Gründe geben, warum das so ist.

[@Bobbel888]

"Proof of Concept" muss man von solchen Menschen einfordern und bis die Integration abgeschlossen ist; viele Consultants sind schon Lichtjahre entfernt, wenn ihr gut gemeinter "Mist" aufschlägt. Mit gut integrieten Workflows dagegen kann man beliebig effizient werden; auch das beängstigt viele, die hierzu keinen Beitrag leisten können oder ihre Ausbrems-Kontrolle verlieren würden.

[@valeridause]

@@Bobbel888 Ich verstehe, dass Sie es ernst meinen. Jedoch. Funktioniert das im Leben niemals. Keiner wird verantworten, was sich er selber oder seine Vorgänger ausgedacht hätten.

[@valeridause]

@@Foreversun33 Stellen Sie sich vor - Sie schauen auf ein Musik-Notenblatt und sehen sie dort komplexes Stück. auf der Titel-Seite steht auch "Hochzeit Sinfonie N35 ". Doch. Auch, wenn die Zeichen im Blatt nach Noten aussehen, zusammengelegt ergeben sie keinen Sinn, manche Stellen sind gar unmöglich gespielt zu werden und auf der Hochzeit diese Ansammlung von chaotischen Tönen würden Sie nie im Leben abspielen wollen. Sie. Weil Sie die Noten z.B. lesen können, und die Musik im Kopf spielen lassen können. Aus diesen 250 Menschen konnte keiner die BPMN. Denen konnte man alles zeigen, was irgendwie nach System- und Prozess-Landschaft aussieht. Sie werden sowieso nichts davon verstehen können, von überprüfen - ist sowieso keine Rede. Was am Ende realisiert wurde, hatte mit den BPMN - Diagrammen danach tatsächlich nichts mehr zu tun. Zum Teil, weil ich mich dazu nett, jedoch konstruktiv geäußert habe, und man solche Sachen nicht mehr öffentlich gezeigt, und zum Teil, weil ich aus dem Kreis der Beteiligten sehr schnell rausgenommen wurde. Damit ich diese Kommunikation - "Experten" zu "Schäffchen" nicht störe. In vielen Firmen stellte ich fest, dass der Schein sehr oft mehr Gewicht hat als Sein.

[@valeridause]

@TheOneWhoKnocksTwice ha-ha. Wie schön, ohne die Details zu kennen, haben Sie schon Urteil gefällt- die Architekten wären gut, und ich habe nur eine Kleinigkeit gesehen und meckere darüber. Sie liegen komplett falsch. Es geht nicht darum, dass ein Pfeil von einem Gateway fehlte oder ähnliches. Die Architektur war so falsch, dass in 7 Jahren Entwicklung (ja,ja 7 Jahren, obwohl es nur 2 vorgesehen waren) wurde die Architektur 3 Mal komplett redesign. Die verwendeten Technologien und Gestaltung. Ich hatte damit, wie gesagt nicht mehr zu tun, doch ich konnte es von der Seite beobachten. Daher, urteilen Sie nicht, was Sie nicht kennen.

[@heikokopp3529]

Hallo Golo, vielen Dank für diese hervorragende Zusammenfassung! In meiner Rolle als Senior Architekt erlebe ich oft, dass die Architektur in Kundenprojekten von Anfang an festgelegt ist und nur schwer geändert werden kann. In letzter Zeit ist es mir jedoch gelungen, einige Kunden dazu zu bewegen, ihre bestehenden Entscheidungen zu überdenken und offen für neue Ansätze zu sein. Natürlich klappt das nicht immer, aber jeder Fortschritt zählt. Dein Video habe ich bereits an alle Entwickler und Architekten in zwei unserer Projekte weitergeleitet und um ihr Feedback gebeten. Es sind etwa 60 Personen - ich bin gespannt, wie viele konstruktive Kommentare daraus entstehen werden. Bitte mach weiter so! Viele Grüße, Heiko

[@mlohr1]

Und? hast du schon Feedback?

[@suikast420]

Genau mein standpunkt.

[@dustsucker4704]

Aus einem unbekannten Grund habe ich zum Ende hin das Gefühl, dass es persönlich wird.😅

[@marcusreinicke]

So Golo, ich habe jetzt noch ein paar Tage darüber geschlafen. Das Thema ist nicht einfach mal eben so abgehakt. Es sind alles Werkzeuge und ein Verhaltenskodex. Diese Prinzipien sind doch durch Erfahrungswerte entstanden. Genau wie Patterns, wurden diese Prinzipien lange bevor sie einen Namen hatten, von dem einen oder anderen verwendet. D.h. es hat sich aus Erfahrung entwickelt. Du hast natürlich recht, dass die Entkopplung mit das ah und oh ist. Je nachdem, wie ich Entkopplung umsetze, befolge ich automatisch, mehrere Architektur und Coding Prinzipien. In erster Linie, sind es Werkzeuge. Ein Schlosser benutzt in der Regel auch einen Maulschlüssel, obwohl er eine Wasserpumpenzange benutzen könnte. Ich finde, wenn einige Prinzipien, mehr Regeln wären, als nur Prinzipien, würde es viel einfacher sein, sich in Projekte einarbeiten zu können, Wartung und Erweiterbarkeit zu verbessern. Coden ist schon durch Wildwuchs so unüberschaubar geworden. Ende der 90er und in die 2000er hinein, hat so wie ich das wahrgenommen habe, keiner in De nach den Prinzipien gearbeitet. Obwohl diese da schon einige Jahre alt waren. Wenn man heute den Code betrachtet, wird einem teilweise echt schlecht. Bei manchen Projekten ist es heute noch so. Weil jeder so rum-programmiert hatte, wie es ihn passte. Dieser Wildwuchs ist doch Kontraproduktiv, oder meinst Du nicht? Ja ich weiß - Entwickler haben Probleme damit. Sehen sich eingeschränkt. In ihrer Freiheit beschnitten. Aber man darf eines nicht vergessen. Man codet nicht für sich. Man codet in einem Team, als Auftrag, und man sollte hier beste Qualität abliefern und auch so, dass nachfolgende Entwickler, sich hier schnell wiederfinden. Nichts ist schlimmer, als ein Entwickler, der meint, sich durch seinen eigenen Entwicklungsstil unabkömmlich machen zu wollen. Ich kenne Diplom Mathematiker, die die Signaturen von Funktionen im Format f(x) gemacht haben. Ja, ist sehr kurz, aber bei vielen Funktionen, wird diese Art der Programmierung unlesbar.

[@davidondracek9498]

Okay… ich muss sagen, dass das Video zwar oft ein Nicken hervorruft - gerade am Ende die Aussage „es gibt nicht DIE Architektur“ - bin nach 20 Jahren Softwareentwicklung kein Freund (mehr) von Dogmen jeglicher Art. An der einen oder anderen Stelle aber Fragen und leichtes Unwohlsein verursacht hat. Allerdings erscheinen mir meine Einwände allesamt viel zu offensichtlich als dass ich mir einbilden würde du hättest sie nicht in Deine Überlegungen einbezogen. Zum Beispiel - was sagst du zu dem Argument, dass man sich mit µServices viel Komplexität (und damit quasi organisatorische Abhängigkeit) einkauft? Würde mich dazu echt gern mit Dir austauschen.

[@m13v2]

zum testen mit mocks muss man code haben, der sich an die tell, don‘t ask regel hält, wodurch der evtl. von einem mock zurückgelieferte wert keine relevanz für den test hat. das hat mit information hiding und oop zu tun und ist u.a. in „growing object oriented software driven by tests“ beschrieben, wobei man dabei als allererstes einen acceptance test schreibt, der ohne mocks arbeitet. von den autoren des buches gibt es auch noch zwei paper zu dem thema die man sich anschauen sollte. und dann gibt es noch ein neueres paper von ferrari das emily bache erwähnt hat.

[@klausklavikus3836]

Sehr gutes Thema ! Das bringt mich sofort zu meinem alten Mentor als ich ihm meine Arbeitsweise damals im Backend zeigte und er mich fragte "Gibts nen Grund wieso du zusammenhängende Abläufe in dutzende Funktionen schmeißt statt in eine einzige ?" Ich meinte "Ja klar ich versuch mich an die Prinzipien zu halten aus den Büchern..." Daraufhin fragte er "Ahja .... Was sagen die schlauen Bücher noch so ?" Ich hab ihm dann den ganzen Kram aufgezählt (DRY-Prinzip, MVC Model etc...). Er meinte dann "Alles klar pass auf, nimm mal die ganzen Bücher und schmeiß die ALLE in die Tonne ! Dann beginnst du DIR SELBER mal Gedanken darüber zu machen was DU für sinnvoll erachtest. Wenn du das dann weißt, kommste wieder und ERST DANN bin ich gewillt meine Hilfe anzubieten ! Das sind alles Fachidioten die denken den heiligen Gral gefunden zu haben und jedermann soll dann bei dem Mist einfach nur stumpf mitmachen ... Es is eine Sache sich ein Konzept anzuschauen ABER wenn ich als Programmierer der Meinung bin das z.B. das MVC-Model einfach nicht in mein Konzept passt, dann wende ichs auch nicht an und gut is. Selbes Spiel mit SCRUM. Agiles Arbeiten gut und schön aber in der Praxis hat sich bei uns Extreme Programming deutlich besser bewährt. Es mag Teams geben wo SCRUM sinnvoll sein mag aber das kann man eben nicht generalisieren !" Das is jetzt gute 3 Jahre her und seitdem hab ich so enorme Fortschritte gemacht durch diesen Menschen das is echt der Wahnsinn 🙌 Leider war ich in meinem letzten Team dadurch überhaupt nicht kompatibel weil die "Clean-Coding" brutal ernst genommen haben und ich mich zum Schluss geweigert habe so einen Blödsinn mitzuverantworten ...

[@alex0kai]

Also schreibst du jetzt Funktionen mit >100 LoC? Manchmal haben Bücher auch Recht :)

[@klausklavikus3836]

@@alex0kai Meistens fasse ich kleinere Abläufe direkt in einer Funktion zusammen. Meine Faustregel is dabei "Nicht mehr als 50 Zeilen Code in einer Funktion". Komplexere Abläufe strukturiere ich so, das ich mir eine Kommentarsektionen erstelle und in darin dann sämtliche zusammengehörende Funktionen schreibe. Ich lehne die Konzepte aus Büchern nicht strikt ab, wenn es sich anbietet und ich es für sinnvoll erachte die Konzepte einzusetzen, dann mache ich das auch 😊 Was ich hingegen fast vollständig abgelegt habe ist das DRY-Prinzip. Grade im letzten Projekt bei dem ich mitgewirkt habe ist es mir wieder stark aufgefallen wie meine Kollegen ständig in die Funktionen schauen mussten um zu verstehen wie diese nochmal was genau verarbeiten. Ich fasse nur noch dann Funktionalitäten zusammen, wenn sie eindeutig sind weil es für mich nur dann sinnvoll erscheint. Oder allgemein ausgedrückt, ich mache aus dem Coding keine Religion mehr wie ich das früher gemacht habe sondern sehe es mittlerweile als schlichtes Handwerk an.

[@alex0kai]

@@klausklavikus3836 naja, kann man jetzt ohne den Code zu sehen meiner Meinung nach nicht bewerten. Zu sagen, dass DRY nicht funktioniert, weil deine Kollegen sich immer den Code einer Methode anschauen müssen, zeugt eher von schlechter benamung und hat nichts mit dem DRY-Prinzip zu tun. Das mit deiner Kommentarsektion habe ich nicht ganz verstanden. Kommentare, die erklären, was im Code passiert, sind eher ein antipattern, da im späteren Verlauf der Code geändert wird, aber die Kommentare nicht angefasst werden und sich dann wundert, warum der Code nicht das macht, was in den Kommentaren steht. Guter Code sollte ohne Kommentare lesbar sein. Aber das sind halt alles sagen aus diesen blöden Büchern. Wir fahren damit gut. Wenn es bei euch anders sehr gut funktioniert ist das ja die Hauptsache und das, worauf es ankommt. Dann ist es ja perfekt für euch. Es darf aber auch nicht zur Religion werden, alles aus der Literatur zu verteufeln. Das geht ja bei dir doch schon eher in die Richtung.

[@klausklavikus3836]

@@alex0kai Warum hängst du dich denn so an den Büchern auf 😂 Die Kernaussage war im Grunde "Denk SELBER NACH und folge nicht stumpf irgendwelchen Prinzipien..." nicht mehr und nicht weniger 👌 Ne das mit der Kommentarsektion verstehst du falsch ^^ Das sieht in etwa so aus: ////////// Select Users With Specific Parameter ////////// ... Funktionen für Abäufe ... /////////////////////////// Das lässt sich in KZbin Kommentaren natürlich sehr bescheiden darstellen aber im Grunde erläutere ich nur welches Resultat am Ende die jeweiligen Funktionen zusammengenommen erzielen sollen. Das ist ja nun auch nichts Neues das ist mir schon des Öfteren so begegnet und ich habs mit der Zeit übernommen weil ich die Strukturierung die dadurch erzeugt wird sehr mag. Schlicht aber effektiv 👍 Ein Kollege von mir macht das beispielsweise mit TODO's aber da bin ich kein Freund von weil es eine Zweckentfremdung der eigentlichen TODO-Funktionalität darstellt. Aber auch das ist mir schon ein paar mal untergekommen 🤷‍♂ Die einzige Sache auf die ich mittlerweile bei Projekten bestehe ist eine "Code-Bible", also eine Beschreibung der zu verwendenden Konventionen. Ich hab an 2 Projekten mitgearbeitet wo keine strikte Konvention vorlag und es war die Hölle 🤦‍♂ Das war ein Gestümper vor dem Herrn das kann ich dir sagen und das waren allesamt "erfahrene" Entwickler... Ne du da bin ich raus, ganz einfach 🤷‍♂

[@marcusreinicke]

Ach Golo. Es sind alles nur Werkzeuge. Aber ich denke, dass man, dann doch die richtigen Werkzeuge verwenden, wenn man in größeren Teams arbeitet. Diese Werkzeuge sollen doch helfen. Dafür sind Werkzeuge da.

[@bootfahrer93]

Ich bin mit dem Mantra "im Zweifel für die Architektur" immer gut gefahren. Als Developer als auch als Architekt. Es dient allen, wenn man respektiert, dass es keine einzige richtige Architektur gibt. Aber es ist förderlich zu spüren, dass es genau eine Architektur für ein Projekt geben sollte.

[@erdwaermung9235]

Danke für das Video. Probier mal aus deine Kamera leicht über deine Augenhöhe zu positionieren, sodass du leicht nach oben in die Kamera schauen musst.

[@LukasRotermund]

Software*-Architektinnen. Für den Titel Architekt muss jemand i.d.R. lange studieren und dann auch noch in die Architektenkammer eingeladen werden. Architekt ist zu recht ist ein geschützter Begriff. Viele meiner Bekannten mit M. Sc. kämpfen lange dafür diesen als Titel tragen zu dürfen und wir zerstören zu Unrecht deren Jobmarkt mit unserer leichtsinnigen Titelverwendung. Kein Front, nur eine Randinformation um Awareness zu schaffen.

[@wingsuit9043]

Danke Golo für deine Videos. Habe viel gelernt von deinen Videos. Hier bin ich mal anderer Meinung. In der Analyse der Architektur gebe ich dir vollkommen recht. Deine Schlussfolgerung kann ich aber nicht nachvollziehen. Ich denke, es gibt viele Anwendungen, die kein Microservice Architektur benötigen. Nicht weil man nicht Netflix ist sondern weil die technisch und realen Kosten einfach zu hoch sind. Dieser Architektur Fehlschluss kommt häufig aus der Psydo Beraterbubble, die eben klassische Architektur als Unprofessionel / altbacken Brandmarken/belächelt und Microservices für jeden Zweck vorschlagen.

[@thenativeweb]

Ich habe nicht gesagt, dass alles auf Microservices basieren sollte. Ich habe gesagt, dass man die Architektur nicht festlegen sollte, bevor man nicht die fachlichen Anforderungen kennt, und dass man etwas anderes als Monolithen zumindest mal in Betracht ziehen sollte. Wenn nach gründlicher Prüfung und Abwägen von Alternativen die bewusste Entscheidung fällt, dass eine monolithische Architektur die beste Wahl ist, ist das doch wunderbar. Ich wehre mich nur dagegen, dass das a) viel zu selten passiert, weil die Architektur eben doch vorher festgelegt wird, und dass b) das Argument "wir sind aber nicht Netflix" dafür ein ziemliche dämliche Begründung ist, weil die Frage, ob man Netflix ist oder nicht, absolut nichts damit zu tun hat, ob eine gewählte Architektur zum gegebenen Problem passt oder nicht.

[@DJME19777]

@@thenativeweb Man kann auch erstmal mit einem Modulithen starten und wenn man merkt, dass es Sinn macht einzelne Module als Microservices extrahieren, sollte dann relativ einfach sein, wenn die Module im Modulithen sauber getrennt wurden. Und dafür muss man die Fachlichkeit gut kennen, von daher ist es erstmal egal, was man für eine technische Lösung man nimmt. Ist die Fachlichkeit nicht sauber herausgearbeitet werden auch die Microservices nicht sauber geschnitten sein

[@k1ngarthur87]

Also ich entwickle immer erstmal Protopen ohne Architektur, irgendwie zusammengeklöppelt. Und immer wenn es zu unübersichtlich wird, zu umfangreich und zu wuselig, dann wird refactored und dann bildet sich nach und nach eine geeignete Architektur ausgerichtet an der Software, die den fachlichen Anforderungen folgt. Irgendwann hat man dann schon die Erfahrung wo, welche Architektur bereits von Anfang an schon absehbar ist.

[@ThePeri4n]

Ganz ehrlich, wenn ich "Architekt" auf einem Profil sehe, lese ich nur noch "Ich wollte nicht mehr programmieren, also male ich jetzt Diagramme." Ich habe meine gesame Junior-Zeit und noch ein paar Jahre danach in amerikanischen Startups verbracht; dort gibt es gar keine Architekten. Wenn dort etwas vorangetrieben wird dann von Entwicklern, die jeden Tag programmieren. Das scheint mir alles ein sehr deutscher Phänomen zu sein.

[@thorstenhirsch]

In Startups übernehmen meist die "Staff Engineers" und "Principal Engineers" diese Rolle. Erst bei größeren Unternehmen werden für die Architektur eigene Stellen geschaffen.

[@Bobbel888]

Ganz ehrlich, wenn ich an Scrum denke und dessen Idee der Selbstorganisation eines Teams, dann verstehe ich, dass die Verlierer in Rollen der Architektur oder des Projekt-Managements flüchten, die Gewinner von der Überbewertung anderer reden und sich damit selbst ein Zeugnis schreiben.

[@MichaelMeierhoff]

Ich denke nicht, dass das ein rein deutsches Phänomen ist. In großen Organisationen mit weit verteilten und komplexen Systemen kann kein einzelnes Team die gesamte Systemlandschaft überblicken. Dafür braucht es Personen mit einem Blick fürs große Ganze - eine “Makro-Brille” -, die idealerweise selbst viele Jahre als Entwickler gearbeitet haben und dadurch über umfangreiche Erfahrung verfügen. Nach Gregor Hohpe sollten diese Architekten den “Architecture Elevator” fahren, um den Kontakt zur Basis nicht zu verlieren. Es benötigt jedoch manchmal auch Architekten auf der Mikro-Ebene, die im Lösungsbereich unterstützen, sei es durch das Einhalten von Prinzipien, die Einführung neuer Technologien oder das Setzen von Leitplanken (Railguards) für eine konsistente Umsetzung.

[@felikowski]

Also was die Tests angeht, kann man aber auch bei 3 Schichten Architektur Scenario Tests bauen (bspw. mit cucumber), wo mittels AppLayer Testdaten in die DB geschrieben werden, die dann validiert werden können

[@glapaxy]

Zum Glück nicht "Gebäude"-Architektur. Aber ist "Architekt" keine geschützte Berufsbezeichnung?

[@thenativeweb]

Ich weiß nicht, wie es bei Gebäude-Architektur aussieht, aber im Softwarebereich ist "Architekt" keine geschützte Bezeichnung, genauso wenig wie zB "Berater".

[@kayschwieger5223]

Netter Auftakt für den Stammtisch. Inhaltlich gehe nur bei einem Punkt mit: Mit der Architektur ihrer Software sollten sich alle (Entwickler) befassen. Der Rest geht i.m.o. am Kern vorbei und ist z.T. inhaltlich verzerrt. Zum Glück habe ich andere Erfahrungen gemacht.

[@lighty5738]

Und ich dachte, ich wäre einfach nur zu dumm, die ganzen Prinzipien zu verstehen, "nicht greifbar" trifft es ziemlich gut. Und wenn etwas nicht greifbar ist, wird es entweder gar nicht akzeptiert oder es wird vollkommen falsch angewendet. Und gerade letzteres hilft ja auch niemandem weiter.

[@alxk3995]

Ich frag mich ja immer welche Firma das wirklich vernünftig hinbekommt. Wir binden ja auch Schnittstellen von größeren, bekannten Firmen an. Und bei jedem merkt man, dass die auch strugglen größere Änderungen vernünftig umzusetzen. Dieses "man ist ja nicht Netflix" ist glaub ich auch nur die Reaktion auf den Trend vor ein paar Jahren, als für alles pauschal Microservices verwendet wurden. Damals hieß es oft "machen wir, weil Netflix macht das ja auch". Mein Argument war "ja aber wir verteilen nicht Petabyte-weiße Medien an Millionen nutzer weltweit". War aber egal, da war ich noch Azubi. 😅 Wenn es eine komplett neue Architektur sein soll, dann muss man halt auch mit einrechnen wieviel Zeit man braucht bis alle Leute im Team fit sind. Diese Zeit hat man bei Projekten oft nicht. Will man irgendwie nicht hören, aber ist halt schon ein Punkt.

[@robotrabbit5817]

Hast du auch Tipps in deiner 360°-Serie wie man mit Kollegen umgeht und sie mitnehmen kann, vor allem wenn sie wenig Ahnung bezüglich Kohäsion, Kopplung und diverser Patterns haben? Vermutlich müssen wir einfach als Gruppe am Workshop teilnehmen :D

[@urthona8800]

Clean Code als Emotionalisierung zu betrachten halte ich für falsch, das Gegenteil ist richtig: es ist die Entemotionalisierung und ja, die Entfernung der persönlichen Handschrift/des Code-Smells durch allgemeine Regeln. Damit jeder auch nach 3 Monaten den Code lesen kann ohne Ablenkung und emotionales Schluckauf. Und auch um Konflikte aufgrund unterschiedlicher Vorlieben für Klammernsetzung etc. zu vermeiden. Ersetzt durch allgemein gültige Grundsätze wie Coding Styles, Semantic Naming etc. In der Konsequenz kommt eher steriler Code heraus.

[@orange-vlcybpd2]

11:38 "Woher kennst du unser Projekt?! 😅" Krass, dass man aus dem verwendeten Architekturmuster direkt die chronischen "Krankheiten" herleiten kann.

[@skrymir1]

Ein Problem ganz anderer Natur. Dieses Status-quo-Bias Getue kann wirklich nerven. Man sollte aber natürlich auch nicht in das andere Extrem verfallen. Aber ein bisschen mehr Modularität würde vielen echt gut tun. Dann würde auch die gesamte Firma nicht noch auf Java 8 hocken. Meines Erachtens eine der besten Episoden bis jetzt.

[@FalcoPunch182]

Deine Kritik am Dreischichtsystemen im Vergleich zu Microservices ist leider unsachlich ist meiner Meinung nach ein Strohmann Argument. Deine Kritik geht auf die Kopplung von Fachlogik mit der darunterliegenden Schicht ein, in deinem Fall die Datenbank. Und dann schwadronierst du, wie unklug Mocking ist. Aber Kopplung über mehrere Schichten hinweg kann ich erstens auch in jedem Microservices reindengeln und zweitens kann man auch 3Schichtsysteme sauber modularisieren und entkoppeln und reine Fachlogik ohne Datenbank-Kopplung schreiben und testen. Hexagonale Architektur ist nicht den Microservices vorenthalten.

[@twiedner]

Kommt wie immer darauf an. Wenn Dein Team die Disziplin hat, solch ein 3tier-System sauber zu halten und es für Euch funktioniert, dann könnt ihr das machen. Er spricht jedoch aus wohl leidlicher Erfahrung (die ich auch in verschiedenen Firmen machen durfte). Er spricht von diesen „gut abgehangen“ und langsam vor sich hingammelnden 3tier-Monstern, die keiner mehr warten, geschweige denn vernünftig testen kann. Und dann kommen von den Entwicklern diese Netflix-Argumente.

[@MSchubert-lt6so]

Ich denke, so ist das auch nicht gemeint. Ich komme immer auf 4 Schichten. Im Prinzip nutzte ich noch so eine Art Use Case Layer, der dann Repo Schicht, Logik Schicht vereint. Die UI nutzt dann diesen Use Case Layer. Mein Ansatz ist simpel, ggfs zu simpel: Logik und Repo gehören nicht vermischt. UI gehört nicht mit Repo oder Logik vermischt Dann kann man die Logik ohne Repo testen. Ich mag keine Mocks. Das erscheint mir in sich widersinnig. Allerdings verstehe ich auch nicht die Ansätze Logging zu mocken. Das ist eigentlich schon durch DI flexibel und man kann die Ausgabe bei Tests auf die IDE biegen. Finde ich eigentlich elegant. Aber kann man kritisieren. Kann ich nachvollziehen.

[@monfort537]

Mocking ist in der Tat unklug, wenn ich die Mocks ändern muss, ohne dass die zu testende Unit aktualisiert wurde. Davon abgesehen, geht es in dem Video aber auch gar nicht darum, dass drei Schichten schlecht und Microservices gut sind. Die Kritik richtet sich gegen die Wahl von Architekturmustern aufgrund von Gewohnheiten, bzw. Vorlieben oder schlicht aus der Angst heraus, etwas falsch zu machen, ohne dabei die fachlichen Anforderungen in den Fokus zu rücken.

[@djcrem00]

Mal ne Frage, wie tested ihr die Geschäftslogik in einer Hexagonalen Architektur ohne Mocks?

[@FalcoPunch182]

@djcrem00 Im Idealfall hat deine Logik keine externen Abhängigkeiten. Objekt geht's rein, wird verarbeitet, Objekt kommt raus. Dadurch kannst du es auch trivial testen. Erfordert halt viel mehr Klassen aber kann von der Technik abstrahieren. Alles andere machst du dann in... Nennen wir es Integration Tests. Also komplette Szenarien testen mit einer Datenbank oder Message Bus oder so. Da kannst du dann aber auch echte Datenbanken usw. nehmen, auch als einfache Dev Container oder so. Alles nicht dogmatisch sehen, aber trotzdem: Versuche Aufrufe zur Datenbank oder in deine allseits beliebte Repository Klasse in deinem fachlichen Code zu vermeiden und arbeite auch super einfachen Objekten.

[@ReneHartmann]

Zur Ehrenrettung von Uncle Bob sei aber gesagt, dass seine Clean Architecture große Ähnlichkeit mit Hexagonal Design hat. Allerdings habe ich nicht den Eindruck, dass sie dem viel Nützliches hinzufügt.

[@anion21]

Ich finde sauber entwickeln auch wichtig, aber dieser "Kult", den du beschreibst, ja, der ist manchmal wirklich skurril. Ich habe auch den Eindruck, dass man primär eine saubere Trennung der Komponentn einer Anwendung in den Vordergrund stellen sollte für langfristige Wartbarkeit, Erweiterbarkeit, etc. Ob man das mit Microservice, hexagonale Architektur oder irgendwelchen anderen Architektur-Prinzipien oder wie auch immer umsetzt, ist dann letztendlich nicht mehr das wichtigste. Da kann man dann im Einzelfall schauen, was für das aktuelle Projekt gerade am besten zu sein scheint. (Das ist wahrscheinlich das, was du mit niedrige technsiche Kopplung meinst.) Das Problem bei der Bewertung für eine gute Archtiektur/Struktur ist denke ich, dass es dafür de facto keine geeigneten messbaren Metriken gibt. Und so bleibt die Diskussion halt oft eher opinion-based.

[@qui-gonkenobi4574]

Hm interessantes Statement zu Mocks. Ich fand die für Unit Test schon praktisch, wenn zb nur einfache Persisitierung „ersetzt“ wird um letztendlich die eigentliche Business Logik zu testen und ich hierfür keine db brauche. Und wenn dies fachlich gut geschnitten wird, wird doch auch Persistierung benötigt 🤔?

[@IndeptStudios]

Starkes Video mal wieder. Treffend zu 100%.

[@thenativeweb]

Vielen lieben Dank 😊

[@orange-vlcybpd2]

Ich frage mich ob das Sechseck im Logo von TNW uns im Kontext des Themas etwas sagen will.. 🤔🤫

[@thenativeweb]

Vielleicht … 😉

[@Oelpfanne]

In unserer Firma war das nie der Fall, dass irgendwelche Prinzipien über allem gestellt wurden. Diese Prinzipien haben aber auch per se nichts mit Architektur zu tun. Wüsste auch nicht, wann das irgendjemand wo behauptet hätte. Clean Code sollte jedem Entwickler vom Prinzip bekannt sein. Man sollte es ganz einfach verstehen, also die Problematik und die Idee dahinter. Dann kann man sowas in seiner Entwicklung einfließen lassen. Aber ich sage immer wieder: nur wenn es im konkreten Fall konkrete Vorteile bringt. Alles sollte man immer sach- und fachbezogen betrachten und hinterfragen. Nichtsdestotrotz sind Architekten meiner Meinung nach wichtig. Irgendjemand sollte sich über Struktur, Konventionen usw. Gedanken machen. Und es sollte nicht der Teamlead sein. Der sollte sich mehr um sein Team kümmern, die Leute fördern, sie motivieren usw. Der Architekt sollte dabei die ganzheitlichen Businessanforderungen und die dazugehörigen Businessprozesse genau kennen. Das erwartet man nicht von einem Entwickler, der sich z.B. nur um einen Teilbereich davon konzentrieren sollte. Es ist sonst einfach zu viel, was der Entwickler kennen und können sollte. Deswegen sehe ich Architekten nicht grundsätzlich als "elitär", aber ich verstehe ungefähr, was mit diesem Video gemeint ist. Deswegen gibt's einen Daumen nach oben!

[@sephirot7581]

"In unserer Firma war das nie der Fall, dass irgendwelche Prinzipien über allem gestellt wurden. Diese Prinzipien haben aber auch per se nichts mit Architektur zu tun. Wüsste auch nicht, wann das irgendjemand wo behauptet hätte. " Die Prinzipen und wie man eine Architektur gestaltet gehen schon gerne oft miteinander ein. Daher finde ich das nicht verkehrt, dass so zu sehen. Sogar R. Martin hat in seinem Buch die Theorie hinter Softwarearchitektur mit den SOLID Prinzipien erklärt, daher passt das auch nicht ganz, dass hätte niemand behauptet

[@Oelpfanne]

@@sephirot7581 Das habe ich aber anders in Erinnerung. Er hat die SOLID Prinzipien als grundlegendes Programmierkonzept vorgestellt. Als Grundlage für Clean Code. Er hat gezeigt, wie das eine oder andere Prinzip innerhalb einer Architektur Anwendung finden kann, aber es macht nicht die Architektur aus. Die Architektur wird vorrangig durch die Struktur definiert und das Festlegen der Art der Wechselwirkungen von Teilkomponenten der Software. Aber SOLID hat wie gesagt so erstmal nichts direkt mit Architektur zu tun. Es ist zwar schon ein wenig her, dass ich Clean Code und Clean Architecture gelesen habe, aber kann mich nicht erinnern, dass R. Martin was anderes sagte

[@mlohr1]

@@Oelpfanne Genauer gesagt fänge mit einen modularen Monlolith an und nach Bedarf könnte man ziemlich einfach ein Modul zum Microservice refactoren...

[@dummywerfer]

Etwas mehr Pragmatismus und die Erkenntnis dass Softwareentwicklung nur Mittel zum Zweck ist wäre angebracht. Letztlich will man vorwärts kommen und mit der Software in der eigentlichen Domäne Geld verdienen. Wird leider oft ignoriert. PS Uncle Bob ist völlig überbewertet und hinterlässt den Eindruck niemals Applikationen für die Praxis entwickelt zu haben.

[@HoD999x]

sobald wir KI driven development als default haben ist das ganze thema obsolet: "skynet, bitte schreib das ganze ding mal eben mit architektur x"

[@dominik4496]

Ich finde Microservices haben in der Praxis was Performance und Komplexität angeht durchaus das Potential sachlich zu rechtfertigen, dass man sie sich fernab eines Budgets von Netflix gut überlegen sollte. Das heißt natürlich nicht, dass man in jedes Shopsystem ein Newsletter System reinwirken muss, wenn es auch anders geht und nicht viele Schnittstellen braucht. Aber hier werden durchaus einige spannende Punkte dazu aufgeführt, auch was die Betriebskosten, Transaktionssicherheit usw angeht kzbin.info/www/bejne/bIbPgJ5_oJV2o7Msi=dlHKhkP6ywdCpRp_

[@motzky]

Simplexity by Werner Vogels ... Prinzipien sind alles

[@rudxde]

TLDR von dem Video: Architektur ist unterbewertet und wir häufig schlecht gemacht. Aber im ernst, all die angesprochenen punkte sind ja Aufgabe des Architekten. Die Software Architektur soll die NFR's des codes sicher stellen und trifft Entscheidungen die meist nicht einfach zu ändern sind - Themen wo Projekte meist dran scheitern.

[@mlohr1]

Nein nicht nur die NFR aber die Fachlichen Anforderungen genau so.

[@dualfluidreactor]

Man sei ja nicht Netflix ist ein korrektes Argument, wenn es um die Bandbreite der Datenleitung geht. Richtig ihr braucht kein petabyte/sekunde

[@CodeInsideCasts]

Etwas lachen muss ich ja schon beim Titel "Architektur ist überbewertet" und ab der Hälfte geht es um die "richtige Architektur" (Microservices... Hexagon...) und am Ende wird der Architekturworkshop angeboten. Etwas arg reißerisch IMHO

[@T0kwe]

Microservices verhindern keine schlechte Architektur, wie von dir impliziert. Auch Microservices kann ich eng aneinander koppeln, wenn mein Schnitt schlecht ist. Das ist sogar ein noch viel größeres Projektrisiko, als wenn nur mein Modulschnitt in meinem Modulithen schelcht ist. In einem Modulithen kann ich mit der IDE Usages finden, Diagramme zeichnen lassen und Refactoring Werkzeuge benutzen. Bei Microservices habe ich dann einen verteilten Monolithen, der Inkonsistenzen (eventual consistency) hat, bei dem ich mir nicht sicher sein kann, ob nicht irgendwelche anderen Services auch an ihn gekoppelt sind, bei dem ich dann zur Nachvollziehbarkeit verteiltes Tracing machen muss, was wieder viel Komplexität mit sich bringt. Von daher ist die Aussage: "Brauchen wir nicht, wir sind ja nicht Netflix." gar nicht so falsch. Solange man einzelne Services nicht unabhängig skalieren können muss, braucht man es wirklich nicht.

[@DJME19777]

Microservices machen vor allem Sinn, wenn man Teams entkoppeln will oder einzelne Funktionalitäten unterschiedlich skalieren will. Ansonsten sind Modulithen evtl. die bessere Lösung. Die Gefahr einen verteilten Monolithen ist sehr groß und bringt einem dann viele Probleme ohne Vorteile ein

[@T0kwe]

@@DJME19777 Da stimme ich dir zu. Um Teams unabhängig voneinander zu bekommen, machen Microservices Sinn. Die sollten dann aber nicht "Micro" sein, sondern so groß wie möglich und so klein wie nötig. Also im besten Fall nur ein Microservice pro Team.

[@thenativeweb]

Ich habe nicht gesagt, dass Microservices eine schlechte Architektur verhindern. Ich habe kritisiert, dass zu oft vorschnell und ohne ausreichenden Überblick eine Entscheidung für die vermeintlich passende(re) Architektur getroffen wird, mit seltsamen Argumenten wie "wir sind nicht Netflix", was in Bezug auf die Architektur überhaupt keine Aussagekraft hat. Natürlich kann man eine gute Struktur auch anders erreichen (das sage ich im Video sogar explizit, dass auch zB ein Monolith die richtige Wahl sein kann), nur darum ging es überhaupt nicht. Der Kern des Videos bzw die Aussage davon war, dass um Architektur ein zu elitärer Affenzirkus gemacht wird, und das langfristig schädlich ist, weil es Menschen abschreckt, sich damit auseinanderzusetzen, weil sie Angst haben, "zu dumm" dafür zu sein.

[@mlohr1]

@@T0kwe das kann man auch mit einem modularen Monolith hinbekommen

[@DogzDeDoggy]

Heutige (Solution/xyz/fancy/..) Architekten sind nur Pattern und Prinzipien Auswähler. Was richtige Architekten machen kann man hier erfahren: kzbin.info/www/bejne/q2i6knZqZ56Mmbcsi=SSsS8fwZOole3xRA

[@StephanRoth]

Zum Thema Testen der Business-Logik in 3-Schichtenarchitekturen (ca. 11:30): "Ach so ... blöd ...geht nicht, ja. Weil, da hängt an dem Business-Logik-Layer leider immer noch die doofe Datenbank mit dran." Tja, mein lieber Golo, hätte man doch das Dependency-Inversion-Principle, das D aus SOLID, gekannt, dann wäre das nicht passiert, dass an dieser Schichtengrenze die Abhängigkeiten in die falsche Richtung zeigen. ;-)

[@thenativeweb]

Ich sehe, Du kannst nicht nur auf LinkedIn polemische und herablassende Kommentare schreiben. Tatsächlich kenne ich das D aus SOLID, und mir ist durchaus bewusst, dass man die Datenbank damit herauslösen kann. Und was genau macht man dann mit der Dependency in den Tests? Üblicherweise wird dann mit einem Stub / Mock / Fake / … gearbeitet, der das Problem aber nur bedingt löst (denn dann fehlt die Garantie, dass sich das im Test so verhält wie die reale Datenbank). Deshalb ist mir eine Architektur, die mir die Datenbank erst gar nicht aufdrängt in der Business-Logik deutlich lieber. Dann muss ich nämlich auch nichts stubben, mocken & Co. Dann kann ich Fachlogik nämlich komplett *ohne* diese Abhängigkeit schreiben, was aus meiner Sicht auch deutlich sinnvoller ist, weil es der Fachlogik schlicht und ergreifend egal ist bzw. sein sollte, ob persistiert wird oder nicht. Das ist ein technisches Implementierungsdetail. Aber hier führen wir genau die Diskussion, die ich kritisiere: Statt die Architekturentscheidung zu hinterfragen, ob es so eine gute Idee ist, den Business-Layer *überhaupt* von der Datenbank (ob nun direkt oder indirekt) abhängig zu machen und mal darüber nachzudenken, wie man das komplett unabhängig gestalten könnte, stellst Du mich lieber als unwissend und ein bisschen doof dar, weil ich Deiner Meinung nach alleine anscheinend zu blöd bin, auf DI zu kommen. Insofern: Danke für Deine Kommentare, die lassen auf persönlicher Ebene tief blicken. Und inhaltlich kann ich nur sagen: Du bestätigst leider genau das, was ich kritisiere. QED.

[@StephanRoth]

@@thenativeweb Ich sehe, Du kannst eine leicht sarkastische und ironische Anmerkung auch dann nicht erkennen, wenn ein Zwinkersmiley dahinter steht. Und damit belasse ich es jetzt auch. Dein Umgang mit Kritik sagt nämlich auch sehr viel mehr über Dich aus, als Dir möglicherweise bewusst ist.

[@pinkeHelga]

Clean Code hinterfagen? Hinterfrag mal das Thema Klimawandel. Danach sind dir Clean-Code-Diskussionen scheiß egal. :))

[@christianhorauf9958]

Was haben so Grundsätzliche Überlegungen wie SOLID oder CleanCode mit Architektur zu tun? Die sind ja eher so grobe Guidelines denen man folgen sollte. Ob Hexagonale oder (ehrlichgesagt hab ich noch nie von einer anderen Architekturmethode gehört, die irgendjemand gut begründen konnte) zu wählen fällt in diese Fragestellung eher rein. Wird aber, wie @Golo richtigerweise sagt, zu selten hinterfragt bzw. angegangen. Aber dieser Rant gegen Uncle Bob gefällt mir nicht. Mami und Papi sollen nicht streiten: kzbin.info/www/bejne/rJbOdaaJlLCFntE Es gibt genug wofür man Uncle Bob menschnlich kritisieren kann, seine technische Expertise möchte ich nicht in Fragestellen, weil sie mir persönlich eine adäquate Guideline gegeben hat.

[@thenativeweb]

Ich habe nicht Robert C. Martin kritisiert, sondern die Leute, die so einen Personenkult um ihn machen. Und SOLID und Clean-Code haben sehr wohl was mit Architektur zu tun - nicht mit Systemarchitektur, aber mit Softwarearchitektur, weil es Prinzipien und Konzepte und Praktiken sind, um saubere Strukturen zu schaffen, und genau das ist der Sinn von Architektur.

[@nilsmach6399]

Ich höre diese Meinung ausschließlich von Leuten, die aus der JavaScript-Ecke kommen, was wenig überraschend ist.

[@thenativeweb]

Tja, blöd nur für die "Argumentation", dass ich gar nicht "aus der JavaScript-Ecke" komme. Ich habe das zwar 10 Jahre lang primär gemacht, bin damit aber weder groß geworden noch habe ich daran die Grundlagen gelernt. Das waren dann eher .NET und Java.

[@nilsmach6399]

⁠@@thenativeweb10-Jahre ist für mich schon ein „Aus der Ecke kommen“. Der Punkt ist, Du lästerst die erste Hälfte über Solid und Clean Code, ohne zu reflektieren, dass die halt sehr Java spezifisch sind und zu JS oft nicht gut passen. Im zweiten Teil findest Du Architektur doch plötzlich ganz wichtig und hebst zu recht die hexagonale Architektur gegenüber der 3-Schichten-Architektur hervor. Allerdings scheinst Du nicht zu wissen, dass Uncle Bob das Buch Clean Architecture geschrieben hat, das im Grunde diese hexagonale Struktur in anderen Worten beschreibt. Clean Code hat also keine Verbindung zur 3-Schichten-Architektur. Auch mit der Gegenüberstellung von Clean Code vs. Microservices, hexagonaler Architektur, … am Ende wirkt das Video so, dass Deine Perspektive tatsächlich aus der JS-Ecke stammt und Du einige Wissenslücken bei dem Thema hast.

[@lintendo100]

Ich finde diese, mehr oder weniger explizite, pauschale Abwertung von JS/TS-Entwicklern in deinem Kommentar ziemlich ekelhaft und arrogant.

[@nilsmach6399]

@@lintendo100 Das hast Du falsch verstanden. JS passt strukturell in mehrerer Hinsicht nicht zu dem Java-fokussierten Clean-Code-Ansatz. Deswegen ist das wenig überraschend. Problematisch ist aber schon, dass JS-Entwickler trotzdem eine sehr starke Meinung dazu haben, ohne die Java-JS Diskrepanz zu reflektieren und sich z. B. auch nicht sonderlich in Clean Architecture auszukennen. Gerade, wenn jemand nur JS-Entwickler ist und sich damit für einen vollkommenen Entwickler hält, dann sollte man ihn aufgrund seiner Einstellung tatsächlich explizit abwerten. Selbst Golo, der sich in x Programmiersprachen auskennt, hat in diesem Video einige Java-bezogene Punkte verfehlt. Wenn Du also nur JS programmierst und denkst, das reicht aber auch, dann solltest Du nochmal denken.

[@devbert1880]

Kein typischer Clickbait-Titel... aber mindestens Clickbait-Stunt :) Wenn DAS die Frischlinge lesen! :) Die glauben das noch und rennen damit los :P Was sollte auch die Alternative sein? "Im Zweifel Yolo-Architektur"? Und am Ende argumentierst du doch pro Uncle Bob + Clean Architecture... o7

[@AnniiLebt]

Bitte ändere den Titel. Dieser ist absolut irreführend. Du redest nicht von Architektur und Architekten, sondern von Software Architektur. Finde es absolut nicht in Ordnung dass dieser Begriff in der IT legal verwendet werden darf, da die Berufsbezeichnung geschützt ist.

[@thenativeweb]

Dass es in einem Video auf einem Kanal über Softwareentwicklung nicht um (bauliche) Architektur geht, sondern um Softwarearchitektur, dürfte naheliegend sein. Da das Video zudem weder unerwartet viele Aufrufe hat noch die Watchtime deutlich kürzer als sonst ist, zeigt das, dass es kaum Leute gibt, die der Titel in die Irre führt - sonst wäre mindestens einer der beiden Werte anders. Insofern scheint der Titel nicht "absolut irreführend" zu sein, und daher erlauben wir uns, den Titel entgegen Deiner "Forderung" nicht zu ändern.