Ich betrachte Software seit meiner Diplomarbeit auch als soziales System. Habe sogar quasi ausversehen und damals unbewußt DDD (Aggregate, Entity, Value Object) aus den drei Zeilen Luhmann hergeleitet, die ich gelesen hatte. Mein damaliger Chef war etwas irritiert (oder empört?), als ich ihm sagte, daß ich in meinem Entwurf keinen Unterschied mache zwischen Softwareservice und einem Service, der von Menschen erbracht wird. Der Wert der Software liegt in der Vermittlung der Kommunikation. Übrigens: „Architektur ist eine evolutionäre Unwahrscheinlichkeit“ - falls Du mal Lust auf intellektuelle Blödelei hast … ;-) Ich meins ernst.
@sLiv2562 ай бұрын
Klingt ja fürchterlich. Die EU reguliert sich in die Bedeutungslosigkeit.
@frankoppermann18773 ай бұрын
Aus dem Video kann man sehr viel für die Praxis mitnehmen. Ist echt Top. Mir ist eine Sache bis dato noch unklar. Wie werden Fremdbeziehungen zwischen verschiedenen Aggregates modelliert. Sämtliche Regeln sehe ich hier nur innerhalb von Aggregates als Consistent Rule. Beispiel: Ich habe Posts und Comments (Parent-Child Beziehung) Wo modelliere ich die Regel, das Posts nur gelöscht werden können, wenn alle dazugehörigen Comments gelöscht worden sind? Vermutlich findet sich der Code im Application-Layer wieder. Aber wie modelliere ich dies im Event-Storming? Natürlich kann man das Problem auch mit einer Policy lösen, indem man nach dem Löschen eines Posts alle dazugehörigen Comments löscht. Aber der Business Case kann ja auch so sein, dass bei existierenden Comments kein Post gelöscht werden darf.
@xelth4 ай бұрын
Wenn du etwas von OpenSSL lernen möchtest bist du falsch heir... spar deine Zeit...
@danel990710 ай бұрын
Sehr schöner Vortrag vielen Dank dafür. Eine Frage hätte ich: Sind DataProducts wirklich nur für analytische Anwendungszwecke gedacht oder gibt es auch operative Anwendungszwecke für DataProducts?
@HelmuthLammer11 ай бұрын
Toller Einblick. Hier hat jemand sehr viel Erfahrung und Ahnung. Ich denke Sie brauchen gar nicht so oft sagen, dass Sie hoffen alle bleiben dran. So uninteressant ist 1. das Thema gar nicht und 2. Wie oft hat man denn die Chance so einen Experten zuzuhören. Danke!!
@Sebastian-zs8cp Жыл бұрын
27:17 was ich nicht verstehe warum man mit events und aggregaten anfängt und nicht mit events und commands? das habe ich gelesen das es mit events angefangen wird und 2. dann mit commands.
@Sebastian-zs8cp Жыл бұрын
kzbin.infoO2FaNcc3yk8?feature=share&t=1083 . Ich die frage auf Vorherig definierten Ziele/goals oder wie komm diese Post-its da ran?
@patrickpeyer7000 Жыл бұрын
Genial, mindestens für mich als sehr strukturierten Menschen. 😉Da ich gerade am Abstecken meiner künftigen MAS-Thesis bin, werde ich die Anwendung dieses Tool gleich einfliessen lassen in meiner Arbeit mit Fokus auf Legacy-Mordernisierung und Platform Engineering.
@moger83 Жыл бұрын
Unterschiede und Implikationen verschiedener Detailtiefen sehr schön beschrieben. Vielen Dank!
@INNOQtv Жыл бұрын
Danke, dass Ihr heute dabei ward! Was sonst schon alles im INNOQ Technology Lunch lief, könnt ihr hier (www.innoq.com/de/technology-lunch/) sehen! Wir wünschen Euch einen schönen Sommer und melden uns im September wieder!
@ThomasPraxl Жыл бұрын
Schön, dass Ihr Team-Topologies mal in eine greifbare Story verpackt und damit anschaulich gemacht habt - auch für Leute, die sich damit bisher noch nicht beschäftigt haben. Übersicht Enabling Team, Stream-aligned Team, Platform Team hier: 42:19. Ich finde auch die Cloud-Native Maturity Matrix sehr schön zur Veranschaulichung, dass wir uns gleichförmig weiterentwickeln müssen bzw alle Dimensionen weiterentwickeln müssen und nicht nur auf einzelne, prominente Aspekte setzen können. Die Matrix ist hier zu sehen 46:11.
@gregglazewski7557 Жыл бұрын
I think it is just a misunderstanding what api first stands for
@tpoky Жыл бұрын
Warum sagt Tammo dauernd "em"????
@marcm3623 Жыл бұрын
12:39 scope/Kontext. Sind Scope und Context etwas das man immer nur gemeinsam betrachten sollte?
@dmlled Жыл бұрын
an amazing and grounded summary of down-to-earth arguments for the ivory tower
@ThomasPraxl Жыл бұрын
Sehr empfehlenswertes Video zum Einstieg und zur Vertiefung in die Thematik. Michael Plöd bereitet das Thema sehr verständlich auf.
@wolfgangschmidt2503 Жыл бұрын
This is a fantastic talk that deserves much more views! I particularly like that Stefan is one of the backend people who recognizes that backends are not the center of the universe everything else circles around.
@BaldOldGermanDude Жыл бұрын
Danke für den prima Vortrag! In meiner Erfahrung ist das schwierige und zeitfressende meist nicht, Lösungen für die Probleme zu finden. Schwierig ist es dann, wenn man die Lösung in einer Matrix-Organisation nicht selbst herbei führen kann. Man muss jemand ANDEREN in einer Matrix-Organisation davon überzeugen müsste, das Problem für einen zu lösen. Eine andere Abteilung, die für Compliance, Datenschutz, Security, WorkplaceManagement oder sonstwas zuständig ist, verharrt dann eben oft auf "Das geht auch anders, nehmt halt das vorhandene Tool", "Das widerspricht unseren ungeschriebenen Prozessen!" oder ähnlichem nicht zielführendem Verhalten wie Ghosting, etc., quasi den ganzen Massnahmen aus dem Sabotage-Handbuchs der Allierten gegen die Nazis des zweiten Weltkrieges... natürlich kann man dann mit Eskalationen, warten auf vierteljahrlich tagende Architekturboards und so weiter dann doch die Lösung erreichen. Schneller und nervenschonender ist aber leider, leider dann immer noch die Lösung mit Shadow IT :(
@85daniel Жыл бұрын
Super Einstieg in die Umstellung. Da sind echt ein paar sehr elegante Features dabei. Danke!
@saturdaysun9545 Жыл бұрын
Gute Erklärung. Super!
@unbekannter_Nutzer Жыл бұрын
Hm. Danke für den Vortrag. Den Teil zu Enums fand ich recht dünn. Der BrushType zeigt, wie man Enums aus anderen Typen, evtl. wiederum Enums, zusammensetzen kann?
@larsr_h Жыл бұрын
BrushType ist ein Enum, welches nicht nur eine einfache Aufzählung repräsentiert (wie Java-Enums), sondern wo die einzelnen Fälle auch noch Parameter enthalten können. Damit kann man grundsätzlich genau das gleiche machen wie mit case classes in Scala 3, aber eben mit kompakterer Syntax.
@cyclingnerd4711 Жыл бұрын
Das Video hätte deutlich mehr Aufrufe verdient! Pragmatisch, wie ich es so oft vermisse. Schöner Ausflug auch in meine CORBA-Vergangenheit (grusel) ;-)
@INNOQtv Жыл бұрын
Hallo, es freut uns, dass es dir gefallen hat, und vielen Dank für das Lob!
@GudeDoc2 жыл бұрын
Vielen Dank für den Vortrag! Bin gerade auf das Video gestoßen und habe den Namen "Gernot Starke" in dem Buch "Software-Architekturen kommunizieren und dokumentieren" von Stefan Zörner im Geleitwort gelesen 🙂
@ThomasPraxl2 жыл бұрын
Quality Storming: 51:27
@MaxMaxMax32 жыл бұрын
Super Infos. Danke
@alexandern.22162 жыл бұрын
Thanks for this awesome talk. It really reminded me on a lot of problems we had in a recent project.
@andreaskoop2 жыл бұрын
👍
@TMaierhofer2 жыл бұрын
I observed in several projects that APIs or even "wannabe achitectures" created in the beginning of projects are heavily defended which is really dangerous for the project if the don't fit.
@BaldOldGermanDude2 жыл бұрын
Punkt 3 kann ich sehr unterschreiben. Auch verwandt mit Hype-Driven-Development oder Resumee-Driven-Development ... und das führt dann zur Cargo-Cult Architektur. Wir machen's, weil man das halt so macht. Hab ich leider auch schon bei ganz großen Projekten gesehen.
@mlohr12 жыл бұрын
Ich war schon bekannt mit Wardley Mapping und hatte auch ein Vortrag von Simon selber erleben dürfen (und viele seine Videos). Aber mein Respekt für dieser Vortrag in wie du, in sehr wenig Zeit so ein Konzept so einfach und gut erklärt hast.
@jensstahl7682 жыл бұрын
Hier spricht jemand mit viel Ahnung!
@zickzack9872 жыл бұрын
Jüngstes praktisches Beispiel: Anwendung für eine Abteilung mit ca 40 Benutzern. 40+ k8s Deployments mit derart wenigen fachlichen Features, dass der Fachbereich nicht gewillt war, es zu benutzen 😊 Nach 1,5 Jahren und Millionen von Euros eingestampft. 🤷🏻♂️
@timvenkman2 жыл бұрын
"Der Dritte wird Sie schokieren" bei nem 51 Minuten-Video lmao Und das bei nem Architekturvideo :D Pathetic
@AlexGuitar19842 жыл бұрын
Wirklich sehr interessant, vielen Dank.
@jfriedrich282 жыл бұрын
tolle Querverbindung DDD / Arc24 :-)
@wonderb0lt2 жыл бұрын
Schöner, kompakter Talk der sich auf die wesentlichen Features konzentriert! Danke!
@bjornzschernack76532 жыл бұрын
Merci beaucoup, das hilft grad sehr beim Verständnis
@moomentma66822 жыл бұрын
Vielen Dank für den praktischen Einblick in der Arbeit mit ArgoCD. Wir verwenden derzeit auch für die Pipeline k8s agents (Jenkins oder gitlabci), für CI/CD sodass wir die kubectl Aufrufe schon im Cluster haben. Es gibt allerdings (außer, dass es einzelne jobs einer Pipeline sind) nicht die strikte Trennung zwischen CI und CD, wobei wir in diesem Fall CD nur für unsere Acceptance Tests verwenden. Für Production Environments sehe ich hier einen klaren Vorteil von ArgoCD, da ja die Deployments fertig sein müssen. In der Entwicklung müsste man jetzt zwischen CI und CD trennen. Das habt Ihr ja auch gemacht, indem ihr ArgoCD aus der Pipeline getriggert habt. Ich könnte mir vorstellen, dass die Trennung zwischen CI und CD den Vorteil bringt, dass Deployment-Templates für die Produktion "abfallen", welche ja in unserem Ansatz aktuell nirgends abgelegt werden, da diese nur sehr temporär für das starten der Acceptancetests und deren Umgebungen verwendet werden. Danke für die Informationen und damit neuen Denkansätze. 😀
@zickzack9872 жыл бұрын
Sollte man potentielle Angriffe immer reporten? Gibt es hierfür Ansätze?
@INNOQtv2 жыл бұрын
Ja, aber die große Schwierigkeit ist, die potentiell gefährlichen/gezielte Angriffe vom Grundrauschen - z. B. automatische Portscans usw. - zu unterscheiden. Dafür ist höchstwahrscheinlich ein Security Information and Event Management (SIEM) nötig, siehe: en.wikipedia.org/wiki/Security_information_and_event_management
@zickzack9872 жыл бұрын
Gibt es eine Liste von klassischen fachlichen Validierungsproblemen wie z.B. negative Bestellmengen?
@INNOQtv2 жыл бұрын
Wir tun’s noch einmal: Am 1.12.2021 gibt’s die 2. Auflage vom INNOQ Technology Day, unserer Online-Konferenz zu Software-Architektur, -Entwicklung, IT-Strategie und digitalen Produkten. Melde Dich jetzt kostenfrei an, die Plätze sind begrenzt! technologyday.innoq.com/
@LukasRotermund2 жыл бұрын
Spannendes und wichtiges Thema! Ich fand besonders die Einleitung in das Thema mit Andreas und die Podiumsdiskussion am Ende am informativsten. Der Abschnitt mit Naturamus wirkte sehr marketing-lastig, aber den konnte man ja im Nachhinein skippen. Ich hätte noch mal ein paar Fragen in Richtung Andreas. 1) Wie nimmst Du formatierte code & pre HTML Elemente in Blogs und in API Dokumentationen war? Diese sind ja häufig mit diversen span Elementen versehen um sie visuell besser darzustellen - z.B. über die js-Library "highlighter.js". Ist das für Dich eine Barriere beim Lesen/ Hören von Code, oder spielt das keine Rolle? 2) In der Informatik stolpert man ja regelmäßig über Diagramme. Sind hier alt Tags wirklich eine effektive Möglichkeit, die Inhalte darzustellen? Oder hättest du lieber eine Darstellung der Diagramme in Textform, wie bspw über "PlantUML", oder die none-js Syntax von Mermaid? Vielen Dank & beste Grüße Lukas
@INNOQtv2 жыл бұрын
Hallo Lukas, vielen Dank für dein Lob und die Fragen. Sie wurden Andreas weiter geleitet und er hat folgendes dazu gesagt: 1) Auf die erste Frage kann ich nicht antworten, da ich nicht programmiere. Einrückungen nehme ich aber über die Braillezeile wahr, was mir einen guten Überblick über die Struktur von Texten jeder Art gibt. Absätze kann ich gut erfassen, aber auch strukturierten Code. Code außerhalb einer IDE zu lesen ist für mich immer schwierig, weil die Formatierung des Codes dann oft verloren geht. Span Elemente als Mittel zur Hervorhebung sind tatsächlich eher störend. 2) Wichtig bei allen informativen Grafiken ist die Vermittlung der relevanten Aussagen. Auch Diagramme vermitteln solche relevanten Informationen, wenn auch oft in deutlich höherer Dichte und Präzision. Das Alt-Attribut sollte nicht genutzt werden, um ein Diagramm in dem höchstmöglichen Detailgrad zu beschreiben, sondern um darauf hinzuweisen, was die Hauptaussage des Diagramms ist. Beispielsweise "Liniendiagramm, das einen Anstieg des Marktanteils von 20% auf 40% innerhalb der letzten 2 Jahre zeigt" (fiktives Beispiel). Die erste und eine der wichtigsten Anforderungen der WCAG 2.1 ist allerdings, dass für jede Grafik eine Textalternative zur Verfügung stehen muss. Jedes Diagramm bzw. jede in einem Diagramm sichtbare relevante Aussage muss also auch als Text beschrieben werden. Die Herausforderung, einen guten Alternativtext für ein Diagramm zu schreiben, minimiert sich dann auf ein Beispiel wie "Liniendiagramm, das den Anstieg des Marktanteils in den letzten zwei Jahren zeigt" oder sogar auf "Liniendiagramm mit Entwicklung des Marktanteils" bzw. auf eine entsprechende Bildunterschrift mit leerem Alt-Attribut.
@LukasRotermund2 жыл бұрын
@@INNOQtv Vielen Dank fürs Weiterleiten und Beantworten meiner Fragen!
@markomarkovic62402 жыл бұрын
Super Vortrag mit sehr vielen nützlichen Tipps. Vielen Dank! :)
@gernot-starke2 жыл бұрын
Sehr cool Ben, ein paar super Tipps dabei!
@Manuel-kp8nz2 жыл бұрын
Tolles Event, sehr informativ!
@mega2252 жыл бұрын
I found that guards can be used with switch expressions e.g: case String s && (s.length() > 0) -> String.format("String %s", s);
@michael-on-code2 жыл бұрын
Thanks for pointing this out. It's defined in the specification of JEP 406 (openjdk.java.net/jeps/406) and I seem to have forgotten many things from there. Besides guards the possibility for a case null and therefore passing in null to the switch is supported, too.