Connect with us

Entwicklung & Code

Event-Driven, Teil 7: Wie man mit Event-getriebener Architektur anfängt


Event-getriebene Architektur klingt zunächst nach einem radikalen Paradigmenwechsel – und das ist sie auch. Doch gerade weil sie auf einer anderen Denkweise beruht, ist der Einstieg oft einfacher, als viele glauben. Entscheidend ist, dass man nicht mit der Technik beginnt, sondern mit dem gemeinsamen Verständnis.


the next big thing – Golo Roden

the next big thing – Golo Roden

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Dieser letzte Teil der Serie zeigt, wie man ein solches System in der Praxis aufbaut, welche typischen Stolperfallen man dabei vermeiden sollte und wie man Event-getriebene Architektur schrittweise einführen kann.

Am Anfang steht kein Code, kein Framework, keine Datenbank – sondern ein Gespräch. Wer Event-getriebene Systeme bauen will, muss zuerst verstehen, was in der Domäne passiert. Und das gelingt am besten im Dialog mit den Menschen, die diese Domäne kennen: den Fachexpertinnen und -experten.

Ein erster Schritt kann sein, gemeinsam Ereignisse zu sammeln: Was passiert in eurem Tagesgeschäft? Welche Abläufe gibt es? Welche Entscheidungen werden getroffen? Was ist wichtig, was ist selten, was ist kritisch?

Dabei hilft es, ganz bewusst in der Sprache der Fachlichkeit zu bleiben – ohne technische Begriffe, ohne JSON-Formate, ohne Implementierungsdetails.

Bewährt haben sich dabei Formate wie Event Storming: Man klebt Events als Post-Its an eine Wand, ordnet sie zeitlich und diskutiert darüber. So entstehen Schritt für Schritt die zentralen Abläufe der Domäne – verständlich, diskutierbar und überprüfbar.

In dieser Phase ist es wichtig, die Sprache ernst zu nehmen: Ein Event wie „Bestellung wurde storniert“ muss nicht nur technisch korrekt sein, sondern es muss auch inhaltlich passen. Und vor allem: Es muss für alle Beteiligten dasselbe bedeuten.

Ein häufiger Fehler ist, Event-getriebene Architektur gleich auf das gesamte System anwenden zu wollen. Das führt oft zu Überforderung – fachlich, organisatorisch und technisch.

Besser ist es, sich ein isoliertes Teilproblem zu suchen – einen Prozess, der in sich geschlossen ist, aber bereits von klassischen Architekturen überfordert wirkt.

Typisch sind:

  • Benachrichtigungsprozesse
  • Abrechnungs- oder Mahnwesen
  • Genehmigungsworkflows
  • Integration mit Drittsystemen

Hier lässt sich Event-getriebene Architektur gut einführen, zunächst als ergänzender Ansatz, nicht als Ersatz für das bestehende System.

Viele Einsteiger verlieren sich schnell in technischen Entscheidungen: Welches Event-Format soll man wählen? Welche Queue verwenden? Wie Event-Versionierung lösen?

Diese Fragen sind wichtig, aber nicht am Anfang. Wer Events als fachliche Beschreibung ernst nimmt, kann diese zunächst einfach als strukturierte Objekte behandeln – selbst ohne Event-Store oder Queue. Die technische Infrastruktur lässt sich nach und nach ergänzen.

Erst wenn klar ist, welche Events entstehen, wann sie entstehen und was sie bedeuten, lohnt es sich, über Serialisierung, Partitionierung und Replikation nachzudenken.

Wer einmal damit beginnt, in Events zu denken, verändert die eigene Sicht auf Systeme dauerhaft. Man beginnt, Abläufe nicht mehr als Abfolge von Methodenaufrufen zu sehen, sondern als Geschichte von Ereignissen. Und das hat viele positive Effekte:

  • Die Kommunikation mit dem Fachbereich wird klarer.
  • Die Modelle werden stabiler.
  • Die Systeme werden flexibler und nachvollziehbarer.
  • Neue Anforderungen lassen sich oft mit vorhandenen Events umsetzen.

Event-getriebene Architektur ist kein Selbstzweck – und keine technische Mode. Sie ist eine Antwort auf Systeme, die zu unübersichtlich, zu gekoppelt und zu schwer veränderbar geworden sind. Wer Systeme baut, die sich natürlich weiterentwickeln lassen sollen, findet in Events ein kraftvolles Werkzeug.

Diese Serie hat den Bogen gespannt – von den Grenzen klassischer Architektur über die Bausteine, Denkweisen und Fallstricke bis hin zum konkreten Einstieg. Wer den nächsten Schritt gehen möchte, findet auf cqrs.com weitere Ressourcen, konkrete Beispiele und vertiefende Konzepte.


(mai)



Source link

Entwicklung & Code

Keine digitale Souveränität ohne europäisches Geld für Rust, Python und Maven


Schwergewichtige Infrastrukturanbieter aus der Open-Source-Welt, wie die Eclipse Foundation (Open VSX), die Python Software Foundation (PyPi) die Rust Foundation (Crates.io) und Sonatype (Maven Central), haben in einer gemeinsamen Erklärung gefordert, die Finanzierung ihrer Dienste auf neuen Strukturen aufzubauen. Europäische Firmen, Organisationen und EU-Behörden stehen nicht nur in der moralischen Pflicht, sich hier zu beteiligen – mehr noch: Sie sollten die Chance nicht verpassen, ihren Einfluss zu erhöhen, um die digitale Souveränität Europas fundamental zu stärken.


Ein Kommentar von Wolf Hosbach

Ein Kommentar von Wolf Hosbach

Wolf Hosbach ist Redakteur bei der iX. Sein Themengebiet ist die Softwareentwicklung.

Bislang hat das Bild, wo die Mittel herkommen, eine klare Schlagseite: In einem Blogeintrag nennt die Rust Foundation eine kleine Gruppe an Unternehmen, die derzeit Kosten tragen – Fastly, Microsoft, Google, Meta, Huawei und AWS. Bis auf Huawei zählen alle zu den US-Giganten. Viele Nutzer, darunter große kommerzielle Unternehmen, bedienen sich einfach nur, ohne was beizutragen.

Gerade die Institutionen der EU, die sich digitale Souveränität auf die Fahnen schreiben, könnten hier mehr leisten. Bisher scheint ihr zentraler Beitrag vor allem in der Regulierung zu bestehen. „Neue regulatorische Anforderungen wie der EU Cyber Resilience Act (CRA) erhöhten die Verpflichtungen zur Compliance und die Anforderungen an die Dokumentation“, heißt es in der gemeinsamen Erklärung der Open-Source-Projekte.

Doch mit der organisatorischen und finanziellen Beteiligung würde sich auch eine große Chance eröffnen, formellen und informellen Einfluss auf die Gestaltung einer wichtigen digitalen Infrastruktur zu gewinnen. Das wiederum dient der Stärkung der europäischen digitalen Souveränität. Denn wer bezahlt, kann üblicherweise mitreden, gerade wenn dies in einem strukturellen Rahmen geschieht – der sich im aktuellen Fall sogar noch von Beginn an mitgestalten lässt. Das sollte Europa nicht verpassen.

Zudem leben wir in Zeiten, in denen sich die US-Regierung einerseits aus Open-Source-Projekten zurückzieht, andererseits aber explizit Open-Source fördert, wenn es zu den proklamierten Zielen passt. Das Dekret zum AI-Act-Plan enthält ein eigenes Kapitel dazu: „Encourage Open Source and Open Weight-AI“. Donald Trump kommentiert sein Dekret mit, „Amerika wird das KI-Rennen gewinnen.“ Das sollte Europa nicht zulassen.


(who)



Source link

Weiterlesen

Entwicklung & Code

Microsoft erweitert Copilot um Anthropic-KI


Microsofts Copilot fußt generell auf KI-Modellen des Partners OpenAI. Weil das nicht gottgegeben ist, führt Microsoft nun schrittweise Alternativen ein: Kunden werden auf KI-Modelle Anthropics umsteigen können, wenn und wann sie das möchten. Bei der Tochter Github ist Anthropic für zahlende Abonnenten des Github Copilot sogar schon erste Wahl im Visual Code Studio.

Los geht es jetzt im Microsoft Copilot Studio, jener Anwendung, mit der KI-Agenten erstellt werden können. Nach einem Opt-in können die Anthropic-Modelle Claude Sonnet 4 und Claude Opus 4.1 aktiviert werden. Wer den vorprogrammierten Agenten namens Researcher im Rahmen des Frontier Program verwendet, kann auch diesen auf Claude Opus 4.1 umstellen. Frontier ist für Kunden gedacht, die stets den neuesten Schrei bevorzugen und dafür höheres Risiko in Kauf nehmen.

Die Umstellung ist nicht monolithisch, sondern soll flexibel sein, sodass unterschiedlichen Aufgaben mit unterschiedlichen KI-Modellen begegnet werden kann. Wird ein Anthropic-Modell gewählt, bleiben die Daten allerdings nicht in Microsofts Cloud sondern wandern zu Amazon.coms AWS, das die Anthropic-Modelle hostet. Das muss natürlich nicht so bleiben; zieht das Angebot, wird Microsoft Anthropic sicher gerne ein Hosting-Angebot unterbreiten.

„Das ist nur der Anfang“, schreibt der für Business & Industry Copilot zuständige Microsoft-President Charles Lamanna in einem Blog-Post, „Wir sind dazu verpflichtet, KI-Modell-Innovation schnell zu liefern.“ Ziel sei, jeden Geschäftsprozess mit KI-Agenten zu verändern. „Und bleiben Sie dran: Anthropic-Modelle werden noch kräftigere Erlebnisse mit dem Microsoft 365 Copilot bescheren.“ Einen Zeitplan dafür verrät der Datenkonzern nicht.

Übrigens: Anthropic ändert zum 28. September seine Nutzungsbedingungen. Ab dann werden Chat-Transkripte und Code-Sessions der Consumer-Versionen von Claude für das Training neuer KI-Modelle ausgewertet, sofern der Nutzer nicht widersprochen hat.


(ds)



Source link

Weiterlesen

Entwicklung & Code

Alle profitieren, kaum jemand trägt bei: Open-Source-Projekte rufen um Hilfe


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Eine Reihe von Infrastrukturanbietern aus der Open-Source-Welt haben gemeinsam eine Erklärung abgegeben, dass ihre stark ausgelasteten Basisdienste ein neues finanzielles Fundament benötigen. Unterzeichner sind unter anderem die Eclipse Foundation (Open VSX), die Python Software Foundation (PyPi) die Rust Foundation (Crates.io) und Sonatype (Maven Central).

In der Erklärung beklagen sie, dass viele, oft auch kommerziell orientierte Nutzer der lastaufwendigen Paketdienste keinen Beitrag leisten. Gemeinsam mit der Community wollen die OS-Dienste nun neue Wege finden und ein faireres Finanzmodell entwickeln. Die jetzige Finanzierung basiere „auf Goodwill und nicht auf Mechanismen mit Verantwortlichkeiten“.

„Regierungen und Unternehmen verlangen Zuverlässigkeit, Sicherheit und Geschwindigkeit“, betont die Rust Foundation im Blog. „Die gemeinsame Erklärung hebt hervor, dass diese Erwartungen mit realen (und steigenden) Kosten einhergehen.“ Diese werden derzeit von einer kleinen Gruppe an Organisationen und Personen getragen – der Beitrag nennt Fastly, Microsoft, Google, Meta, Huawei und AWS. Währenddessen bedienen sich andere Nutzer bei Crates.io nur, ohne einen nachhaltigen Beitrag zu leisten. Dazu zählen auch kommerzielle Unternehmen, die enormen Wert mit Rust erzeugen.

Neben Quellcode finden sich in den Verzeichnissen immer mehr große binäre Pakete als SDKs, die nur in einem kommerziellen Kontext funktionieren. Hinzu kommen steigende staatliche Anforderungen an Transparenz, Sicherheit und Dokumentation, unter anderem auch aus Europa: „Neue regulatorische Anforderungen wie der EU Cyber Resilience Act (CRA) erhöhten die Verpflichtungen zur Compliance und die Anforderungen an die Dokumentation.“

Die gemeinsame Erklärung schlägt nun folgende Wege vor:

  • Kommerzielle Partnerschaften je nach Nutzung und mit strategischen Vorteilen für die Partner
  • Gestaffelter Zugang zu den Diensten mit erhöhter Performance oder Erreichbarkeitsgarantien für die Partner
  • Mehrwertdienste wie Nutzerstatistiken

Dabei handelt es sich noch nicht um konkrete Vorschläge, betonen die Projekte in ihrer Erklärung, sondern um einen ersten Diskussionsbeitrag. Aber der Rust-Blog enthält auch eine leise Drohung: „Der Zugang zu Crates.io wird sich in der unmittelbaren Zukunft nicht ändern.“ Was nach „unmittelbar“ kommt, darüber schweigt Rust.

In den nächsten sechs bis zwölf Monaten plant die Rust-Foundation Foren für Diskussionen aufzusetzen, sich mit Maintainern und Führungspersönlichkeiten des Ökosystems zu beraten und eng mit anderen Paket-Registries zusammenzuarbeiten. Dabei hebt die Rust Foundation die Bedeutung der Community hervor: „Nichts wird sich ohne extensiven Input der Community ändern“. Hilfe erhoffen sich die OS-Projekte unter anderem durch mehr Beteiligung am Diskurs und die Bereitschaft, die Nutzung der Services auch mit Verantwortung zu verbinden sowie Build-Dienste infrastrukturschonend einzusetzen. Und insbesondere natürlich durch den Willen, Finanzpartner quelloffener Software zu werden.


(who)



Source link

Weiterlesen

Beliebt