Inhaltlich Verantwortliche gemäß § 6 MDStV: Thomas Bayer, Tobias Polley
Haftungshinweis: Trotz sorgfältiger inhaltlicher Kontrolle übernehmen wir keine Haftung für die Inhalte externer Links. Für den Inhalt der verlinkten Seiten sind ausschließlich deren Betreiber verantwortlich.
Skalierung ist ein Grund. Es gibt den Ansatz ein zentrales Gateway zu verwenden. Immer öfter werden aber mehrere Gateways eingesetzt. Oft auch verschiedene für spezielle Aufgaben z.B. eines für extern erreichbare API, eines für den Kubernetes Cluster, eines in der Cloud, ...
Bei Module habe ich Interfaces und Interfaces haben Daten. Wo kommen die Daten (Entities) her?. Diese muss ich oft auch duplizieren, dass ist ein kleiner Nachteil. Microservices haben den Vorteil, dass Code auch eher entsorgt werden kann - der Scope ist begrenzt. Microservices können in der passenden Technologie entwickelt werden - es muss nicht alles homogen sein. Mit Mircoservices kann man Menschen "skalieren". Micro- und Macro-Sevices können auch mit Module implementiert werden.
Karavan or KAOTO which one is better for using Camel 4 version? What is the difference between Karavan and KAOTO as both are Low Code No code visual editor for Apache Camel?
Good question. The visual editor of Karavan looks to me very similar to Kaoto. Maybe they share even common code but I do not know. Karavan provides not only an editor but also runtime support. I have the impression that Karavan is more mature but maybe I am wrong and I cannot tell which one is better. Because they share the same file format and components it is possible to exchange editors without any modification. Maybe you can share your experience with tools.
Ich hätte eine Frage. Ich prauche eine serverlose Datenbank die ich sie in meine Projekte als eine Klasse integrieren kann. Gibt es uberhaupt so etwas. Ich interessiere mich für php Projekte.
Serverless Datenbank findest du z.B. bei Amazon AWS oder bei MS Azure. Aber Vielleicht suchst du einfach eine kleine DB, für Tests oder eine, die du mit deiner Anwendung ausliefern kannst. Für Java gibt es da embeddable Databases, die auch im Hauptspeicher laufen z.B. die H2. Immer öfter nehmen wir aber für solche Zwecke einfach einen Docker Container mit einer Postgres.
Thomas, over the many years I have watched your teams videos on integration and its always professional and honest review. Thanks for taking an eye on Camel again, and what the low-code UI Karavan can do. Its fantastic work by Marat. The Camel project itself (in particular camel-core) provides a lot of structured information for tooling (also 3rd party) and that is what makes Karavan possible. As you say in the video. The UI is 100% standard Camel and as Marat has said Karavan is a "Visual DSL of Camel". The output of Karavan is 100% files that can run in Camel (camel-main, camel-spring-boot, or camel-quarkus) with anything else (no Karavan, or other products). That separation is very important IMHO; which makes gitops possible and for anyone to build and deploy Camel as they need. And your team is surely welcome to take a look at camel jbang (its a power tool) that can make you 10x faster and better with Camel. Its a bit hard to explain but when you got started using it, you would not go back. I personally use it every day and makes me a lot more productive.
Ich bin ein wenig entsetzt. Das Beispiel Abruf von Kundendaten über das Internet spricht doch klar gegen Basic Auth. Du hast hier eine schützenswerte Ressource, wo sichergestellt werden muss, dass ein Aufrufer berechtigt ist, eine solche Schnittstelle abzurufen. In der Regel beschränken sich Prüfungen mit ob Nutzer und Passwort übereinstimmen. Wer aber kümmert sich um Schwachstellen in Bezug auf Brute Force Angriffe. Des Weiteren sendet man das Passwort bei Basic Auth im Klartext. Man muss Sorge tragen, dass solche Header in keinen Logs landen, weil wie bereits erwähnt, ein Zurücksetzen des Passwort nicht möglich ist. Bei hardkodierten auf dem Server kommt erschwerend hinzu, dass ich einen Nutzer nicht einfach sperren kann. Außerdem muss ich mich darauf verlassen, dass alle im Prozess beteiligten Personen die Credentials sicher verwahren. Werden sie kompromitiert, ist ein Wechsel nicht möglich. Aus meiner Sicht ist das Absichern von Schnittstellen mit Basic Auth, über die sensible Daten übertragen werden etwas, was man auf keinen Fall machen sollte.
Was mich vor Jahren an dem ganzen Thema total ernüchtert hat sind Proxies, welche SSL-Verschlüsselung aufbrechen. Der Browser fragt beim Proxy, der Proxy leitet weiter, bekommt vom Server die Daten SSL-Verschlüsselt, der Proxy entschlüsselt, prüft (=verarbeitet), verschlüsselt mit seinem Proxy-Zertifkat und schickt es an den Browser und der Browser merkt davon exakt null, weil das Proxy-Zertifikat im Browser (getestet mit den offiziellen Downloads vom [damals noch] IE, Chrome, Firefox, Opera, Safari) auf die Wildcard * hinterlegt ist. Und das Tolle: der Proxy muss nicht Mal konfiguriert werden sondern wird - dank DHCP/DNS - stets gezogen (sprich: alle Anfragen gehen pauschal an die IP des Proxy). So ein Ding beim ISP aufgestellt und der ganze SSL-Zauber ist vorbei. Da ist es dann egal ob Basic-Auth, Oauth2, gegenseitiger Zertifikatsaustausch, oder was auch immer. Da hilft nur das Protokoll zu wechseln, weil der Proxy das dann nicht mehr versteht. Allerdings sollen "gute Proxies" das aufbrechen nicht nur mit SSL beherrschen, sondern auch mit diversen anderen Protokollen wie SSH, Wireguard, usw..
Könnte man den JMediator theoretisch mit dem CQRS-Pattern vergleichen, und somit auch Sachen von AxonIQ dafür verwenden? Ich finde die Features von AxonIQ auch u.a. nützlich für sowas.
Ja, durch die Unterscheidung von Abfrage und Befehl, kannst du Lesen und Schreiben unterschiedlich behandeln. Für den Mediator könnte man Eventsourcing Infrastruktur wie z.B. AxonIQ einsetzen. Besonders, wenn man die Tools bereits im Einsatz hat. Der Charme von Jimmy Bogart's MediatoR ist, dass er embedded läuft und keine zusätzlichen Abhängigkeiten benötigt.
Super, dass das Thema auch endlich bei Java in Deutschland ankommt. Aber das mit den Dateien ist kein Zwang. Wenn die Quelldateien *über alle Schichten* hinweg in einem Package sind, ist das in auch Ordnung. Die Gruppierung nach Feature ist, glaube ich, auch nur eine Vorliebe und sollte als Ratschlag gesehen werden. Es ist durchaus vorstellbar, dass der Slice ein ganzes (DDD)-Aggregat ist. Eine Alternative zum Mediator ist ein Command Bus (wie z. B. der von clouddogu). Damit kann keinen Stream von Handler erzeugen, sollte aber für die Fälle, bei denen man die Vor- und Nachbearbeitung eines Commands nicht explizit von der eigentlichen Verarbeitung trennen möchte, ausreichend sein.
Danke für den Tip mit dem Command Bus. Vielleicht ist der von clouddogu eine Alternative. Das Projekt schaue ich mir mal genauer an. Die Spring Application Events gehen z.B. nicht, da es keinen Rückweg gibt. Apache Artemis oder NATS könnte man einsetzen, aber das wäre nicht mehr so leichtgewichtig.
Danke natürlich erstmal für die Mühe, solch ein Beispiel zu erstellen. Aber wenn ich mir die Details so anschaue, dann hat es schon seinen Grund, warum man das bisher in der Java-/Spring-Welt nicht findet. 😄 Ich war schon kurz davor, einen langen Kommentar über die diversen fragwürdigen Dinge zu formulieren. Aber ich glaube ich belasse es dabei festzustellen, dass ich als Software-Architekt da nichts wichtiges verpasst habe und unsere Entwickler damit nicht behelligen muss. 😄
Danke für deine Einschätzung. Die VSA halte ich auch nicht pauschal für die Architektur, die zu jedem Projekt passt. Momentan beobachte ich, dass es mit der Hexagonalen und Clean Architekture übertrieben wurde und man sich einen einfacheren Ansatz mit weniger Abstraktionen wünscht. Das könnte auch eine "normale" Spring Boot Anwendung sein. Bei manchen Projekten könnte ich mir durchaus vorstellen, dass die VSA passt: wenig oder nur einfache Businesslogik, hohe Fluktuation im Team, hoher Anteil an Junior-Entwicklern. Wie so oft gibt es in der IT keinen Königsweg.
@@thomas-bayer Ich weiß, was Du meinst. Genau vor dem Problem stehen wir auch gerade mit einem neuen Projekt. Zu wenig Entwickler, Fluktuation, zu viel Junior. Leider wird dadurch die Komplexität der vor uns liegenden Aufgabe nicht geringer. Machen wir uns nichts vor. Wenn heutzutage noch inhouse entwickelt wird, dann muss das gut begründet sein und vor allem dazu dienen, einen Business Value zu schaffen, den die Lösung vom Markt so nicht bietet. Ich gebe Dir sofort Recht, dass man nicht übertreiben darf mit den Schichten und Abstraktionen. Da kann man sich auch drin verlieren. Aber ich sag Dir mal meine Meinung, wo eigentlich das Hauptproblem der meisten Software-Projekte liegt: Dass a.) bereits alte Legacy-Systeme vorhanden sind, die man irgendwie ablösen muss, und niemand weiß mehr so genau, was die alles tun und warum. Und b.) die Fachbereiche einem nicht sagen können, was sie eigentlich wollen und wo die Reise hingehen muss - in einer Weise, die man versteht und in ein Design gießen kann. Denn wenn das alles klar wäre, dann kannst Du relativ straight forward beginnen, dein DDD machen, deine Bounded Contexts schneiden und schön nach und nach als Module umsetzen - und dabei noch schrittweise das Altsystem ablösen - die Würgefeige lässt grüßen. Aber wie gesagt brauchst Du dafür Leute, die wissen was sie wollen und andere Leute (dein Team), die wissen, was sie tun. 😀
@@TPolley Aber genau darum geht es ja, weil zwischen 1999 und 2024 nun eben eine "Lücke" von 25 Jahre klafft ;-). JWT wurde ja bereits behandelt. API-Keys wurden im Video erwähnt, dies wäre die Variante, bei der es sicherlich genug Spielarten gibt (HMAC, Digest Authentication). mutualTLS und Certificate Pinning wären auch noch zu nennen. Nun, genug Stoff fürs nächste Video!
Super Video, das sollte jeder IT-Absolvent einmal gesehen haben! Ich finde es prima, wie du die Unterschiede, aber v.a. die Gemeinsamkeiten der Architekturen herausstellst.
Jetzt bin ich auf das Beispiel gespannt. Denn eigentlich habe ich das Gefühl, dass hier jetzt irgendwie alles durcheinander gewürfelt wird: Software-Architektur, Modularisierung, Repository-Aufteilung. Ich kann und sollte doch auch mit jeder beliebigen Schichtenarchitektur die Ziele von minimierter Koppelung und maximaler Kohäsion erreichen. Das gebietet doch schon das DDD, wo wir Bounded Contexts identifizieren und daran unsere Modularisierungsschnitte ausrichten. Sprich jedes Modul entspricht einer gewissen Fachlichkeit. Die Gesamtheit der Module bildet die vertikalten Schnitte. Natürlich verwende ich dann innerhalb jedes Moduls eine Schichtenarchitektur - egal ob wir die jetzt Onion oder sonstwie nennen. Wie viele Repositories ich daraus mache, steht doch auf einem ganz anderen Blatt. Theoretisch kann alles in einem Repo sein, oder jedes Modul hat sein eigenes Repo, oder ich teile sogar jedes Modul noch auf mehrere Repos auf (lieber nicht). Und auch ob ich das ganze später als Modulith oder Microservices deploye bleibt dabei noch offen. Also, was ist jetzt der Clou an der Vertical Slices Architecture? Dass ich nicht fachlich im Sinne von DDD schneide, sondern technisch/organisatorisch nach umzusetzenden Features? Das klingt für mich nicht wirklich viel versprechend. Ein Feature ist schließlich kein Ordnungsbegriff, den man in einer Architektur vorfindet, sondern lediglich als Ordnungskriterium in der Projektorganisation während der Umsetzung. Ich finde es generell auch nicht hilfreich, dass selbst im Jahre 2024 immer wieder neue Säue durchs Dorf getrieben werden. Eigentlich sollten wir Architekten wohl langsam mal wissen, wie man Software sinnvoll schneidet und organisiert.
Klingt erstmal so, als würde man auf den einzelnen Ebenen Code duplizieren, um Abhängigkeiten zu vermeiden? Selten sind die einzelnen Use-Cases absolut orthogonal...
Was für ein Gefasel, ohne Mehrwert und in sich absolut inkonsistent. Nach vier Minuten war ich dann endgültig raus, es ging nicht mehr, nachdem du dein KundenRepository Interface in die BLL gepackt hast, kurz nachdem du die klaren Abhängigkeiten nach unten definiert hattest. Wie implementierst du denn ein Interface aus einer Schicht auf die du gar keinen Zugriff hast? Das ist lächerlich. Auch wie du am Anfang die Architekturen einfach mit DDD zusammen gewürfelt hast. DDD kannst du mit jeder Architektur machen, das hat rein garnichts damit zu tun. Ich arbeite seit 25 Jahren in Enterprise Umgebungen und Software Projekten mit hunderten bis tausenden Entwicklern. Overarchitecturing, genauso wie Overengineering, sind Haupt-Faktoren warum Software Projekte scheitern. Viel wichtiger als das hier ist immer eine gute, einfache Implementation (oder besser technisches Design), die einfach dokumentiert ist, Clean Code und saubere Trennung vor allem durch naming (bsp: Controller, Manager, Service) damit jeder Entwickler sofort weiß, wo was zu finden ist, und gute Contracts dazwischen. Starre, unverständliche Anwendungsarchitekturen, die meist nur der Architekt versteht der aber niemals eine Zeile Quellcode geschrieben hat, sind kontraproduktiv und stiften nur Verwirrung. Es ist im Kleinen (Anwendungs-Architektur) wie im Großen (Deployment-Struktur) das Gleiche, nur ein bisschen mehr wird immer gleich richtig viel teurer am Ende. KISS Prinzip, oder du bist einfach nur schlecht in dem was du tust.
Super Einfuehrung :) Ich habe letztens noch eine BA von der HHU gelesen, wo die Erfinder sich einig waren, dass die Modelle mehr oder weniger dasselbe in Gruen sind. Interessant finde ich da die Blogbeitraege von Jimmy Bogard ueber seine Erfahrung bzgl Onion-Architektur und der daraus resultierenden Vertical Slice Architektur. Ich hoffe die wurde fuer das naechste Video geteasert :)
Irgendwie ist es alles die gleiche Suppe. Mich irritieren eher die Versuche, für die eigentlich immer gleichen Prinzipien ständig neue Namen zu erfinden. Erstmal: Es sind doch alles Schichten-Architekturen. Und natürlich gab es auch schon vor 25 Jahren Abstraktionen durch die Trennung von Interface und Implementierungen. Ok, wir hatten da noch keine DI-Frameworks, aber sowas wie Factories und Service-Provider. Neue Begriffe wie "Ports" einzuführen und mit einer hexagonalen Architektur irgendeine Bedeutung auf die Zahl 6 zu legen, halte ich für unnötig und täuscht diffuse Neuerungen vor, wo gar keine sind. Die Onion Architektur bleibt leider eher vage in diesem Video. Es bleibt z.B. unklar, wieso die Infrastruktur ganz außen ist, obwohl da offenbar sowohl externe Infrastruktur (z.B. eine REST-API) als auch interne (Persistenz-Schicht) dazu gehört. Für mich auf diesem Level nicht nachvollziehbar. Dann kommt noch die Clean Architecture, um die Verwirrung komplett zu machen. Irgendwie ähnlich zur Zwiebel und der Bienenwabe, aber schon wieder andere Begriffe auf anderen Abstraktionsebenen. Wo würde man z.B. Controller und Use Cases in der Zwiebel finden? Oder wieso sind Presenters auf gleicher Ebene wie Controller?
Hallo @marcom, danke für deinen ausführlichen Kommentar. Der Unterschied zur klassischen Schichtenarchitektur ist bei den drei Architekturen die Unabhängigkeit zur Infrastruktur mittels Dependency Inversion. Ansonsten sind alle drei gleich und unterscheiden sich wie du schreibst nur im Namen, den Bezeichnungen und in der Notation der Diagramme. Selbst die Anzahl der Schichten ist in allen drei Ansätzen variabel. Die Diagramme, die in den Beschreibungen der Architekturen verwendet werden, unterscheiden sich, aber das ist nur Darstellung. Einige sehen da Unterschiede oder Vorschläge zur Einteilung der Schichten. Die Persistenz-Schicht gehört nicht zum Kern der Anwendung, zumindest nicht die Implementierung der Schicht. Intern werden nur die Schnittstellen z.B. für Repositories festgelegt (Hex: Port, Onion: Domain Services, Clean: Application Layer), die Implementierung z.B. KundenNoSQLRepository wird weiter außerhalb angesiedelt (Hex: Adapter, Onion: Infrastructure, Clean: Interface Adapters). Controller findest du im Zwiebelbeispiel von Palermo ganz außen in der Infrastrukturschicht. Use Cases sind in der Zwiebel in der Domain Schicht. Dass selbst Palermo sich nicht festlegt, wo genau was angesiedelt ist („The first layer around the Domain Model is <<typically>> where we would find interfaces…“) trägt sicher zur Verwirrung bei.
Man trennt in Interface und Implementierung, um Komponenten zu bilden. Andere Module können das Interface kennen, die Implementierung ist aber verborgen, d.h. ein anderes Modul hat nur eine Abhängigkeit auf die Schnittstelle. Das trägt zur Gliederung und Flexibilität der Anwendung bei. Die Trennung benutzt man dann, wenn man abstrahieren möchte. Die Abstraktion hat aber auch ihren Preis. Es kann daher sinnvoll sein, in Interface und Implementierung zu trennen oder auf das Interface zu verzichten.
Hatte eine lustige Erfahrung damit. Team A hat einen Teil vom Schema und Team B nen anderen Teil. Team B nutzt einen Modeller in dem das ganze Schema abgebildet ist. Bei Änderungen wurde das ganze Schema gedropped und man hat sich gewundert wo auf einmal die ganzen Testdaten waren😂
Interessant ist auch wie Stripe es mit der Versionierung macht: es wird bei jeder Versionsänderung auch ein "ChangeSet" für Abwärtskompatiblität erstellt. So dass jede bisherige Version auch mit bedient werden kann. Gut erklärt in der Docu mit dem Titel: "APIs as infrastructure: future-proofing Stripe with versioning"
Deshalb lässt man Entwickler nicht an Datenbanken rum frickeln. Für so etwas gibt es Leute, die etwas von Datenbanken verstehen. Und statt seltsamen Übergabetabellen verwendet man procedures und Views, die den Anwendungsentwicklern zur Verfügung gestellt werden. Da gab's vor vielen Jahren schon Talks zB. von Zalando zu. Das Problem mit den Verbindungen kann man auch problemlos lösen, für so etwas gibt es z.B. pgbouncer. Microservice.... Noch mehr unnötiger Quatsch. Vielleicht vernünftige Datenbanken verwenden und Leute, die wissen, was sie tun.
In meinem Bereich kommt das regelmäßig vor… auch dass das Reporting bricht. Die Kunden sagen Observability nur sehr selten vor einem Change Bescheid, deshalb sind meist auch die Kunden selbst verantwortlich dafür, ihre SQL-Abfrage zu pflegen. Schreiben in fremde Datenbanken tun wir nur äußerst ungern, wäre zeitweise zwar praktisch, oft scheint es aber so, als ob die Betreiber von sich glauben, die einzigen zu sein, und dass man als Observability-Team nichts Besseres zu tun hat, als alle 5 Minuten die Notizen aus den Tiefen eines Intranets zu ziehen.
Ich war verblüfft, als unsere neuen junioren meinten sie hätten eine Datenbank entwickelt. Es war expressjs. Offenbar ist durch die Cloud das Verständnis etwas verzogen, was eine Datenbank ist, . De facto haben sie in ihrem leben wahrscheinlich immer mit irgendwelchen Rest APIs gearbeitet, und dies so in ihrer Vorstellung mit einer Datenbank gleichgesetzt. Immerhin verwenden sie eine Abstraktionsschicht, bei dem Videotitel fühlte ich mich jedoch direkt angesprochen.
@@maddinek Die Cloud hat Microservices aufgrund der Skalierbarkeit populär gemacht. Kenne keinen Microservice der nach vorne SQL spricht. Aber ich nehme an du weisst da mehr?
@@MegaBaellchen klar, die Cloud hat Microservices durch die Skalierbarkeit gepusht. Aber das ist nicht alles. Microservices sind auch beliebt, weil sie flexibel einsetzbar sind, unabhängig vom OS laufen und leichter redundant gestaltet werden können. Und ja, Microservices reden nicht direkt SQL (bzw sollten nicht), aber sie nutzen oft ORMs oder andere Abstraktionsschichten, um auf Datenbanken zuzugreifen. Ein Microservice, der Benutzerinfos verwaltet, könnte intern mit einer SQL-Datenbank kommunizieren, bleibt aber modular und unabhängig. Hab aber nach wie vor keine Ahnung was das mit Junioren und der Cloud zu tun haben soll? Anscheinend solltet ihr bessere Leute einstellen.
@@maddinek Na wenn du Monolithen baust hast du den connectionpool direkt zur DB irgendwo in deinem Stack. Ob mit ORM oder nicht, du arbeitest direkt mit der Datenbank. Mit Microservices hast du an der Stelle aber Rest oder GraphQL oder andere Protokolle. Darum kommen die Cloud natives, denen beigebracht wird Microservices statt Monolithen zu bauen, seltener direkt mit der Datenbank in Kontakt, bzw. sie setzen den Microservice der mit der Datenbank spricht mit der Datenbank selbst gleich. Aber gut ich glaub wir drehen uns im Kreis.
Keine Ahnung, woran Du gedacht hast, aber vermutlich haben die meisten Datenbank-Experten an der Stelle des Videos an das große Softwarehaus in Walldorf gedacht, dessen Logo zufällig auch blau ist. Aber Entscheidungen für oder gegen bestimmte Software-Produkte sind oft auch mehr politischer, denn technischer Natur.
Bei uns wird die Datenbank fast überall als Schnittstelle verwendet. Dazu kommt eine Regional übergreifende Replikation. Jedes größere Update ist der Horror und kostet so viel Zeit, Planung, Downtime... Leider fehlt bei uns jeglicher Wille etwas zu verbessern, wenn es nicht gerade ein fertiges "DevOps" Tool gibt welches man halbherzig auf das Problem werfen kann.
Ja Trigger, damit wäre das Beispiel noch besser. Am besten ganz viele über alle Tabellen verstreut mit Stored Procedures und mit viel herstellerspezifischen Funktionen 😉.
