Connect with us

Entwicklung & Code

Event-Driven, Teil 1: Wenn klassische Architekturen an ihre Grenzen stoßen


Die meisten heute eingesetzten Softwaresysteme folgen klassischen Architekturmustern: Sie basieren auf einem relationalen Datenmodell, nutzen eine Schichtenarchitektur und stellen ihre Funktionen über eine REST-API oder eine Weboberfläche zur Verfügung. Dieses Vorgehen ist weit verbreitet, gut dokumentiert und in vielen Fällen auch ausreichend – zumindest auf den ersten Blick.


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.

Doch mit zunehmender Komplexität treten wiederkehrende Probleme auf. Die Anwendungen werden schwer verständlich. Änderungen sind riskant. Die ursprüngliche Fachlichkeit ist im Code kaum noch zu erkennen. Warum ist das so?

Das klassische CRUD-Modell (Create, Read, Update, Delete) ist intuitiv und direkt. Es orientiert sich an Tabellen und erlaubt einfache Operationen auf Daten. In kleinen Systemen oder Admin-Oberflächen ist das oft völlig ausreichend.

Doch sobald Anwendungen eine gewisse Komplexität erreichen – zum Beispiel durch Regeln, Zustandsübergänge oder Abläufe mit Nebenwirkungen –, stößt das Modell an Grenzen. CRUD speichert nur, was geändert wurde – nicht warum. Es macht keine Aussagen darüber, was passiert ist, sondern lediglich, wie der neue Zustand aussieht.

Und das ist ein Problem: Denn sobald Fachlichkeit nicht mehr direkt sichtbar ist, wird das System intransparent. Der Code beschreibt dann nicht mehr die Abläufe, sondern nur noch die Daten, die dabei herauskommen. Das führt dazu, dass die fachliche Bedeutung verloren geht.

Wenn Architekturen die Fachlichkeit nicht abbilden, zeigt sich das in der Praxis sehr schnell:

  • Die Systeme werden schwer verständlich – selbst für die, die sie entwickelt haben.
  • Änderungen sind riskant, weil niemand sicher sagen kann, welche Auswirkungen sie haben.
  • Workarounds häufen sich, weil sich neue Anforderungen nur schwer in das bestehende Modell integrieren lassen.
  • Die Anwendung wird über die Zeit hinweg langsamer, fehleranfälliger und unflexibler.

Hinzu kommt: Klassische REST-APIs und synchroner Datenaustausch zwischen Systemen führen zu starker Kopplung. Systeme warten aufeinander. Fehler propagieren sich. Es entstehen fragile Ketten aus Aufrufen und Abhängigkeiten.

Der zentrale Denkfehler liegt in der Reihenfolge: Viele Architekturen beginnen beim Datenmodell. Es wird überlegt, welche Tabellen oder Dokumente gebraucht werden – und erst dann wird über Abläufe und Fachlogik nachgedacht.

Doch Fachlichkeit entsteht nicht aus Daten. Sie entsteht aus Vorgängen. Aus dem, was Menschen tun – aus Abläufen, Entscheidungen und Zustandsübergängen. Erst daraus ergeben sich die Daten.

Wenn man Fachlichkeit durch die Brille des Datenmodells betrachtet, zwingt man sie in ein statisches Schema. Das mag zu Beginn funktionieren, führt aber mittelfristig zu unflexiblen Systemen – weil das Modell sich nicht mehr natürlich mitentwickeln kann.

Statt mit Tabellen und APIs zu beginnen, sollte man bei den fachlichen Abläufen ansetzen: Was passiert in der Domäne? Welche Vorgänge treten auf? Welche Entscheidungen werden getroffen? Welche Konsequenzen hat das?

Diese Denkweise ist der Kern von Event-getriebener Architektur (Event-Driven Architecture, kurz EDA): Nicht Daten stehen im Zentrum, sondern Ereignisse. Dinge, die passiert sind. Dinge, die eine Bedeutung haben. Und Dinge, auf die andere reagieren können.

Das führt zu einer ganz anderen Struktur von Systemen: Sie werden modularer, entkoppelt, nachvollziehbar – und orientieren sich an dem, was das System eigentlich tun soll.

Im nächsten Teil dieser Serie schauen wir uns die Bausteine einer Event-getriebenen Architektur genauer an: Commands, Events, Projections, Event-Streams und mehr. Damit wird sichtbar, wie aus fachlichen Vorgängen technische Strukturen entstehen – und wie daraus robuste, verständliche Systeme werden.


Aufmacher Sonderheft

Aufmacher Sonderheft

(Bild: iX)

Im Sonderheft iX Developer Praxis Softwarearchitektur gibt es neben den klassischen Architekturinhalten zu Methoden und Pattern Artikel über Soziotechnische Systeme, Qualitätssicherung oder Architektur und Gesellschaft. Domain Driven Design ist ebenso ein Thema wie Team Topologies, KI und Sicherheit. Als Autoren konnte die Redaktion bekannte Expertinnen und Experten gewinnen, die ihr Wissen in vielen spannenden Artikeln sowohl für Architektureinsteiger als auch Spezialisten weitergeben.

Das Sonderheft lässt sich im heise shop erwerben.


(mai)



Source link

Entwicklung & Code

Rails-Entwicklerinnen und -Entwickler forken sich von Heinemeier Hansson weg


Eine Gruppe von Ruby-on-Rails-Entwicklerinnen und -Entwicklern ruft in einem offenen Brief dazu auf, einen Fork von Rails ins Leben zu rufen, der sich vom Gründer David Heinemeier Hansson (DHH) distanziert.

Der Aufruf an das Rails-Core-Team und die Community schlägt vor, die Zusammenarbeit mit Heinemeier Hansson abzubrechen, Rails mit einem neuen Namen zu forken und einen modernen Code of Conduct aufzustellen. Die Unterzeichnenden werfen Heinemeier Hansson private rassistische und transphobe Ansichten vor und berufen sich insbesondere auf zwei Blog-Einträge von ihm: „As I remember London“ und „Gender and Sexuality Alliances in primary school at CIS?!“.

Dass das Vorhaben der Rails-Gruppe sich vermutlich als schwierig erweist, sehen die Autoren selbst: „Wir erkennen an, dass das ein schwieriger Prozess ist … Wie auch immer, wissen wir es nicht, wenn wir es nicht probiert haben.“ Der Aufruf firmiert unter dem Namen Plan vert nach einer französischen Sabotagegruppe aus dem Zweiten Weltkrieg, die Anschläge auf Eisenbahneinrichtungen verübt hat.


X-Kommentare

X-Kommentare

David Heinemeier Hansson (DHH) antwortet bislang nur in einem X-Kommentar direkt auf den offenen Brief.

David Heinemeier Hansson hat bisher nur in einem X-Kommentar direkt auf den offenen Brief reagiert: „Das ist die gleiche Handvoll hysterischer Individuen, die dieselben Riten und Rituale aufführen, wie sie es jedes Jahr machen“.

In den Tagen zuvor gab es schon Unruhe in der Ruby-on-Rails-Community, da Ruby Central Projekte wie RubyGems an sich gezogen hat, ohne andere Maintainer und die Community im Vorfeld in diese Schritte einzubinden.


Update

26.09.2025,

10:37

Uhr

Inzwischen gibt es ein X-Posting von Heinemeier Hansson: „Dieser dämliche Brief, der zu nichts führen wird, hat nicht einmal 50 Unterschriften gesammelt. Wer mit klarem Verstand würde auch so eine offensichtliche Selbstdeklaration als ‚Stell mich niemals ein‘ unterschreiben.“


(who)



Source link

Weiterlesen

Entwicklung & Code

Künstliche Neuronale Netze im Überblick 10: Graphneuronale Netzwerke


Neuronale Netze sind der Motor vieler Anwendungen in KI und GenAI. Diese Artikelserie gibt einen Einblick in die einzelnen Elemente. Der zehnte Teil der Serie stellt graphneuronale Netze vor.


Michael Stal

Michael Stal

Prof. Dr. Michael Stal arbeitet seit 1991 bei Siemens Technology. Seine Forschungsschwerpunkte umfassen Softwarearchitekturen für große komplexe Systeme (Verteilte Systeme, Cloud Computing, IIoT), Eingebettte Systeme und Künstliche Intelligenz.

Er berät Geschäftsbereiche in Softwarearchitekturfragen und ist für die Architekturausbildung der Senior-Software-Architekten bei Siemens verantwortlich.

Graphneuronale Netzwerke (Graph Neural Networks, GNN) erweitern das Konzept der neuronalen Berechnung von regulären Gitternetzen auf unregelmäßige Graphstrukturen und ermöglichen so Deep Learning für Daten, deren Beziehungen sich am besten durch Knoten und Kanten ausdrücken lassen. Ein Graph G besteht aus einer Menge von Knoten V und einer Menge von Kanten E zwischen diesen Knoten. Jeder Knoten i trägt einen Merkmalsvektor xᵢ, und das Muster der Kanten codiert, wie Informationen zwischen den Knoten fließen sollen.

Im Zentrum vieler GNNs steht ein Paradigma der Nachrichtenübermittlung. In jeder Schicht des Netzwerks sammelt jeder Knoten Informationen von seinen Nachbarn (aggregiert sie), transformiert diese aggregierte Nachricht und aktualisiert dann seine eigene Merkmalsdarstellung. Durch das Stapeln mehrerer Schichten können Knoten Informationen aus immer größeren Nachbarschaften einbeziehen.

Eine der einfachsten und am weitesten verbreiteten Formen der Graphfaltung ist das Graph Convolutional Network (GCN). Angenommen, wir haben N Knoten mit jeweils einem d-dimensionalen Merkmalsvektor, die in einer Matrix X ∈ ℝᴺˣᵈ gesammelt sind. Sei A ∈ ℝᴺˣᴺ die Adjazenzmatrix des Graphen, wobei Aᵢⱼ = 1 ist, wenn eine Kante vom Knoten i zum Knoten j besteht, und sonst Null. Um die eigenen Merkmale jedes Knotens einzubeziehen, addieren wir die Identitätsmatrix I zu A, wodurch à = A + I entsteht. Anschließend berechnen wir die Gradmatrix D̃, wobei D̃ᵢᵢ = Σⱼ Ãᵢⱼ ist. Eine einzelne GCN-Schicht transformiert X nach folgender Regel in neue Merkmale H ∈ ℝᴺˣᵈ′:

H = σ( D̃⁻½ · Ã · D̃⁻½ · X · W )

Hier ist W ∈ ℝᵈˣᵈ′ eine lernbare Gewichtungsmatrix und σ eine elementweise Nichtlinearität wie ReLU. Die symmetrische Normalisierung D̃⁻½ Ã D̃⁻½ stellt sicher, dass Nachrichten von Knoten mit hohem Grad diejenigen von Knoten mit niedrigem Grad nicht überlagern.

Nachfolgend steht eine minimale PyTorch-Implementierung einer einzelnen GCN-Schicht. Ich erkläre jeden Schritt ausführlich.

In diesem Code ist die Adjazenzmatrix ein dichter Tensor der Form (N, N). Zunächst fügen wir Selbstschleifen hinzu, indem wir mit der Identität summieren. Anschließend berechnen wir den Grad jedes Knotens, indem wir die Zeilen von à summieren. Durch Ziehen der inversen Quadratwurzel dieser Grade und Bilden einer Diagonalmatrix erhalten wir D̃⁻½. Multipliziert man D̃⁻½ mit beiden Seiten von Ã, erhält man die normalisierte Adjazenz. Die Knotenmerkmale X werden mit der Gewichtungsmatrix W multipliziert, um sie in einen neuen Merkmalsraum zu transformieren, und schließlich mischt die normalisierte Adjazenzmatrix diese transformierten Merkmale entsprechend der Graphstruktur. Eine ReLU-Aktivierung fügt Nichtlinearität hinzu.


import torch
import torch.nn as nn

class GCNLayer(nn.Module):
    def __init__(self, in_features, out_features):
        super(GCNLayer, self).__init__()
        # Gewichtungsmatrix W der Form (in_features, out_features)
        self.weight = nn.Parameter(torch.randn(in_features, out_features))
    
    def forward(self, X, adjacency):
        # Selbstschleifen hinzufügen, indem die Identitätsmatrix zur Adjazenz hinzugefügt wird
        A_tilde = adjacency + torch.eye(adjacency.size(0), device=adjacency.device)
        # Berechne die Gradmatrix von A_tilde
        degrees = A_tilde.sum(dim=1)
        # D_tilde^(-1/2) berechnen
        D_inv_sqrt = torch.diag(degrees.pow(-0.5))
        # Symmetrische Normalisierung: D^(-1/2) * A_tilde * D^(-1/2)
        A_normalized = D_inv_sqrt @ A_tilde @ D_inv_sqrt
        # Lineare Transformation: X * W
        support = X @ self.weight
        # Nachrichten weiterleiten: A_normalized * support
        out = A_normalized @ support
        # Nichtlinearität anwenden
        return torch.relu(out)


Durch Stapeln mehrerer solcher Schichten verbessern sich die Ausgaben, zum Beispiel:


class SimpleGCN(nn.Module):
    def __init__(self, input_dim, hidden_dim, output_dim):
        super(SimpleGCN, self).__init__()
        self.gcn1 = GCNLayer(input_dim, hidden_dim)
        self.gcn2 = GCNLayer(hidden_dim, output_dim)

    def forward(self, X, adjacency):
        h1 = self.gcn1(X, adjacency)
        # h1 dient als Eingabe für die nächste Schicht
        h2 = self.gcn2(h1, adjacency)
        return h2


Wir ermöglichen jedem Knoten, Informationen von Knoten zu sammeln, die bis zu zwei Hops entfernt sind. Für eine Klassifizierungsaufgabe, bei der jeder Knoten i ein Label yᵢ in {1,…,C} hat, können wir die endgültigen Ausgaben H ∈ ℝᴺˣᶜ mit einem Kreuzentropieverlust paaren, genau wie bei einer gewöhnlichen Klassifizierung, und durch Gradientenabstieg trainieren.

Über GCNs hinaus berechnen aufmerksamkeitsbasierte Graphennetzwerke kantenspezifische Gewichte, die einem Knoten mitteilen, wie stark er sich auf jeden Nachbarn konzentrieren soll. Das Graph Attention Network (GAT) führt lernbare Aufmerksamkeitskoeffizienten αᵢⱼ ein, die wie folgt definiert sind:

eᵢⱼ = LeakyReLU( aᵀ · [ W·xᵢ ∥ W·xⱼ ] )

αᵢⱼ = softmax_j( eᵢⱼ )

wobei ∥ die Verkettung bezeichnet, a ∈ ℝ²ᵈ′ ein lernbarer Vektor ist und softmax_j über alle Nachbarn von i normalisiert. Die Knotenaktualisierung lautet dann:

hᵢ′ = σ( Σⱼ αᵢⱼ · W·xⱼ ).

Die Implementierung einer GAT-Schicht von Grund auf folgt dem gleichen Muster der Nachrichtenübermittlung, erfordert jedoch die Berechnung von eᵢⱼ für jede Kante und anschließende Normalisierung. Bei großen Graphen verwendet man spärliche Darstellungen oder Bibliotheken wie PyTorch Geometric, um die Effizienz zu gewährleisten.

Graph Neural Networks eröffnen Anwendungsmöglichkeiten in der Chemie, der Analyse sozialer Netzwerke, Empfehlungssystemen und der kombinatorischen Optimierung. Sie bieten eine prinzipielle Möglichkeit, Darstellungen strukturierter Daten zu lernen, bei denen der Kontext jeder Entität durch ihre Beziehungen definiert ist.

Der nächste Teil der Serie beschäftigt sich mit Transformern, einer neuronalen Architektur, die vollständig auf Aufmerksamkeitsmechanismen basiert und ohne Rekursion und Faltung auskommt, um Sequenzen parallel zu verarbeiten.


(rme)



Source link

Weiterlesen

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

Beliebt