⚙️ Nachrichtenorientierte vs. datenorientierte Orchestrierung – von Daten zu Wissen

der 17. April 2026

Aus Gründen des Urheberrechts wird das in diesem Artikel behandelte Anwendungsgebiet nicht näher erläutert, obwohl es eng verwandt ist. Für weitere Informationen wenden Sie sich bitte an Omer. Er beantwortet Ihre Fragen gerne und entschuldigt sich für etwaige Unannehmlichkeiten.

In diesem Artikel untersuchen wir zwei grundlegende Ansätze zur Software-Orchestrierung:

  • Nachrichtenorientierte Orchestrierung: über Symfony Messenger synchron bzw. asynchron
  • Datenorientierte Orchestrierung: über Navi für synchrone und Flow für asynchrone Orchestrierung

Die Fallstudie basiert auf einem klassischen, aber strukturierenden Problem: Text Mining angewendet auf eine Reihe von Git-Repositories.
Zur praktischen Demonstration werde ich auf das EIT-Tutorial aus den Jahren 2007/2008 zurückgreifen, das damals mit Matthieu Beyou im Rahmen der Informatik-Tutorien zum Thema Klassifizierung durchgeführt wurde.
Für die Daten verwenden wir die von Omer (ehemaliger Arbeitskollege), die auf seiner Website https://git.arkalo.ovh (über die API) verfügbar sind.

Ziel ist es nicht, das beste Machine-Learning-Modell zu entwickeln, sondern zu verstehen, wie die Form der Orchestrierung die Komplexität, Lesbarkeit und Skalierbarkeit des Systems beeinflusst.

Das Problem: die Umwandlung von Datenbeständen in nutzbares Wissen

Der Datensatz besteht aus einer Liste von Git-Repositories, die in einer repos.json-Datei definiert sind, sowie den Daten der Verzeichnisse, die unter https://git.arkalo.ovh/explore/repos aufgelistet sind.

Zur Information: Sie können die Informationen mithilfe des Composio-Connectors für https://composio.dev/toolkits/gitea extrahieren. Die Implementierung finden Sie in meinem vorherigen Artikel: https://blog.darkwood.com/fr/article/relacher-les-connecteurs-des-outils-au-langage.

Jede Einzahlung wird zu einem kanonischen Dokument, das aus Folgendem erstellt wird:

  • Repository-Name
  • Beschreibung
  • README
  • Metadaten (Inhaber, Themen…)

Dieses Dokument wird anschließend mithilfe einer klassischen Text-Mining-Pipeline transformiert:

  1. Vorbehandlung (Reinigung, Tokenisierung)
  2. Merkmalsextraktion
  3. TF-IDF-Gewichtung
  4. Ähnlichkeit zwischen Dokumenten
  5. Klassifizierung / Clustering

Diese Pipeline ist direkt von historischen Ansätzen inspiriert:

  • TF-IDF: Gewicht = tf * log(N / df)
  • Kosinusähnlichkeit zwischen Dokumenten
  • Überwachte Naive-Bayes-Klassifizierung
  • Unüberwachtes k-Means-Clustering

Uns interessiert hier nicht der Algorithmus, sondern die Art und Weise, wie er orchestriert wird.

Hinweis: Falls Sie Dokumentationen bevorzugen, finden Sie im Abschnitt „Ressourcen“ am Ende des Artikels eine Liste mit Themen rund um Data Mining in der Informatik.

Geschäftsprozess-Pipeline (unabhängig von der Orchestrierung)

Zuallererst muss das Kerngeschäft isoliert werden.

Repository → Document → Tokens → Features → TF-IDF → Similarity → Results

Diese Pipeline stellt eine Datentransformation dar.

Jeder Schritt:

  • nimmt ein Datenelement entgegen
  • erzeugt neue Daten
  • ohne starke Abhängigkeit von einem externen Kontext

Genau hier weichen die beiden Ansätze voneinander ab.

Ansatz 1 Nachrichtenorientiert – Orchestrierung über Symfony Messenger

Bei der nachrichtenorientierten Implementierung wird die Pipeline nicht als kontinuierliche Datentransformation ausgedrückt.

Sie wird in einer Nachricht gekapselt und anschließend über den Symfony-Bus ausgeführt.

Ausführungsmodell

Command → Message Bus → Handler → PipelineService → Stages

Konkret ausgedrückt:

  • ein CLI-Befehl löst die Ausführung aus Es wird eine Nachricht gesendet
  • Ein Handler kümmert sich um die Ausführung
  • Das Kerngeschäft bleibt in einem Shared Service zentralisiert.
RunMessengerPipelineMessage
→ RunMessengerPipelineHandler
→ PipelineService

Trennung der Verantwortlichkeiten

Diese Umsetzung erfüllt eine wichtige Projektvorgabe:

Das Kerngeschäft wird von beiden Ansätzen strikt geteilt.

Also :

  • Messenger enthält keine Geschäftslogik
  • Er orchestriert lediglich die Ausführung

Tatsächlich ausgeführte Pipeline

Der Handler löst eine deterministische Pipeline aus:

1. ingest
2. preprocess
3. feature build
4. classification
5. clustering

Jeder Schritt wird in einem gemeinsamen Anwendungsdienst (PipelineService) ausgeführt.

Von Messenger eingeführte Konzepte

Die Orchestrierung führt explizit Folgendes ein:

  • eine Nachrichtenklasse
  • ein fester Ansprechpartner
  • eine Abhängigkeit vom Bus
  • eine Dispatch-Schicht
Command → Message → Handler → Service

Diese Elemente sind spezifisch für Messenger und existieren nicht im datenorientierten Modell.

Beobachtbarkeit und Debugging

Messenger bietet ein natürliches Debugging-Modell:

  • Nachrichtenprüfung
  • Middleware
  • Busprotokollierung
  • Erweiterbarkeit in Richtung asynchroner/warteschlangenbasierter Verarbeitung
Debug = niveau message + middleware

Art des Overheads

In diesem MVP ist der Aufwand konzeptionell messbar:

  • Einführung einer künstlichen Botschaft
  • Indirektion über Handler
  • die Notwendigkeit, die Ausführung um den Bus herum zu strukturieren

Dieser Overhead entsteht jedoch im Orchestrierungsadapter und nicht in der Hardware.

Zusammenfassung

Dieser Ansatz wandelt die Pipeline wie folgt um:

eine verteilte Arbeitseinheit

Sie bevorzugt:

  • Symfony-Standardisierung
  • Erweiterbarkeit in Richtung asynchron
  • Integration in das Ökosystem

Dies geschieht um den Preis einer zusätzlichen Umgehungsebene.

Konzeptuelles Beispiel

final class ComputeTfIdfMessage
{
    public function __construct(public DocumentId $id) {}
}

final class ComputeTfIdfHandler
{
    public function __invoke(ComputeTfIdfMessage $message)
    {
        $document = $this->repository->get($message->id);
        $vector = $this->tfidf->compute($document);

        $this->bus->dispatch(new ComputeSimilarityMessage($vector));
    }
}

Vorteile

  • starke Entkopplung
  • Resilienz (Wiederholung, Warteschlange)
  • native Parallelisierung
  • Symfony-Standard

Strukturelle Einschränkungen

Das Problem wird schnell deutlich:

➡️ Die Nachricht wird zu einem künstlichen Umschlag

Wir manipulieren:

  • IDs
  • persistente Zustände
  • indirekte Übergänge

Das Problem ist ganz einfach:

data → transformation → data

Dies führt ein:

  • der Standardtext
  • implizite Abhängigkeiten
  • ein Verlust der allgemeinen Lesbarkeit

Ansatz 2 Datenorientiert - Orchestrierung über Navi (synchron) und Flow (asynchron)

In der datenorientierten Implementierung wird die Pipeline als geordnete Sequenz von Aktionen, die auf einen Kontext angewendet werden ausgedrückt.

Es ist keine Nachricht vorhanden.

Es gibt keine Versandabwicklung.

Es gibt nur:

  • ein Datenelement
  • ein Kontext
  • eine sequentielle Transformation

Ausführungsmodell

Command → WorkflowRunner → Actions → PipelineService → Data

Konkret ausgedrückt:

Ein Befehl löst einen Workflow aus Der WorkflowRunner führt eine Liste von Aktionen aus

  • jede Aktion transformiert einen Context Die Geschäftsdienste sind identisch mit denen von Messenger.
WorkflowRunner
→ PipelineStageAction[]
→ Context
→ PipelineService

Pipeline-Struktur

Die Pipeline ist explizit als Sequenz definiert:

[IngestAction,
 PreprocessAction,
 FeatureBuildAction,
 ClassificationAction,
 ClusteringAction]

Jede Aktion:

  • nimmt einen Context
  • wendet eine Transformation an
  • gibt einen neuen Context zurück

Art des Kontextes

Der Kontext wird zum zentralen Objekt:

  • es enthält den Pipeline-Status
  • es entwickelt sich in jeder Phase weiter
  • es ist überprüfbar
Context₀ → Context₁ → Context₂ → ... → Contextₙ

Von Flow eingeführte Konzepte

Dieser Ansatz führt Folgendes ein:

  • explizite Aktionen
  • ein Läufer
  • ein sich entwickelnder Kontext
Data → Action → Data

Im Gegensatz zu Messenger:

  • keine Nachricht
  • kein Handler
  • kein Bus

Beobachtbarkeit und Debugging

Der Debugging-Prozess ändert sich grundlegend:

Debug = suite d’actions + snapshots de contexte

Vorteile :

  • sichtbare Ausführungsanordnung
  • überprüfbarer Zwischenzustand
  • deterministische Pipeline

Wesen der Lesbarkeit

Die Pipeline kann direkt als Datenstrom gelesen werden:

ingest → preprocess → features → classification → clustering

Ohne strukturelle Transformation.

Strukturelle Überkopf

Die eingeführten Kosten sind anders:

  • Notwendigkeit eines Kontextes
  • Abstraktion durch Aktionen

Aber :

  • kein Umschlag
  • keine Busumleitungen
  • keine Unterbrechung des Datenflusses

Zusammenfassung

Dieser Ansatz wandelt die Pipeline wie folgt um:

eine Reihe von Datentransformationen

Sie bevorzugt:

  • sofortige Lesbarkeit
  • direkte Transformation von Daten
  • Fehlen eines Umschlags
  • deterministische Pipeline
  • einfaches Testen

Grenzen

  • weniger geeignet für komplexe verteilte Systeme
  • erfordert strikte Disziplin hinsichtlich der Reinheit der Transformationen.
  • Werkzeug weniger standardisiert als Messenger

Direkter Vergleich

| Kriterien | Nachrichtenorientiert | Datenorientiert | | --- | --- | --- | | Mentales Modell | Ereignisse / Nachrichten | Datenströme | | Lesbarkeit | fragmentiert | linear | | Overhead | hoch (Nachrichten, Handler) | niedrig | | Skalierbarkeit | ausgezeichnet | hängt vom Design ab | | Debuggen | indirekt | direkt | | Geschäftliche Verflechtung | schwach, aber diffus | stark, aber explizit |

| Erscheinungsbild | Messenger | NaviFlow | | --- | --- | --- | | Zentraleinheit | Nachricht | Kontext | | Orchestrierung | Bus + Handler | Runner + Aktionen | | Fluss | indirekt | direkt | | Debugging | nachrichtenorientiert | datenorientiert | | Overhead | Nachricht + Handler | Aktion + Kontext | | Pipeline | gekapselt | explizit |

Kernpunkt: die Illusion der Komplexität

Im Falle von Text Mining sind die einzelnen Schritte:

  • rein
  • deterministisch
  • funktional

Beispiele:

  • TF-IDF → einfache mathematische Formel
  • Ähnlichkeitskosinus → normalisiertes Skalarprodukt

Es besteht kein natürliches Bedürfnis nach Nachrichten.

Die Einführung von Messenger ist daher eine architektonische Entscheidung, keine geschäftliche Notwendigkeit.

Haupteinblick

Nachrichtenorientiert wandelt Daten in Ereignisse um.
Datenorientierte Technologie wandelt Daten in Daten um.**

In einem solchen System:

  • Nachrichtenorientiert fügt eine Ebene hinzu
  • Datenorientiert enthüllt das Modell

Auswirkungen auf Symfony

Symfony entwickelt sich in Richtung:

  • asynchron
  • Arbeiter
  • Sidekicks (FrankenPHP)
  • verteilte Orchestrierung

Dies wirft jedoch eine grundlegende Frage auf:

👉 Muss wirklich alles über Nachrichten koordiniert werden?

Die Antwort hängt von der Problemstellung ab.

Wann welche Methode anwenden?

Nachrichtenorientiert

  • verteilte Arbeitsabläufe
  • lange Aufgaben
  • widerstandsfähige Systeme
  • Branchenveranstaltungen

Datenorientiert

  • analytische Pipelines
  • Datentransformationen
  • deterministische Systeme
  • intensive Berechnungen

Quellcode

Der Quellcode des Projekts ist kostenlos und kann hier eingesehen werden: https://github.com/matyo91/omer-quotes

Abschluss

Dieses Projekt demonstriert eine einfache Sache:

👉 Orchestrierung ist nicht neutral

Zwei funktional identische Implementierungen können Folgendes erzeugen:

  • radikal unterschiedliche Systeme
  • gegenläufige kognitive Kosten
  • divergierende evolutionäre Kapazitäten

Im Falle von Text Mining:

  • Die Nachrichtenorientierung macht die Dinge komplizierter
  • Datenorientierte Klärung

Symfony Messenger orchestriert eine Pipeline als Arbeitseinheit.
Darkwood Flow orchestriert eine Pipeline als Datentransformation.

Nächste

Der nächste Schritt im Projekt ist:

  • Erweiterung der Pipeline (Clustering, Klassifizierung)
  • um fortschrittlichere Modelle zu integrieren
  • eine API bereitstellen
  • Vergleich der tatsächlichen Leistung

Aber am wichtigsten:

👉 hinterfragen Sie weiterhin die Form der Orchestrierung.

Ressourcen

Vielen Dank für das Schreiben des Artikels.

  • Omers Git-Repository für Daten und Inspiration: https://git.arkalo.ovh
  • Nutzen Sie Messenger, um Ihre Architektur zu verbessern - Artikelgliederung von Tugdual Saunier: https://speakerdeck.com/tucksaun/tirez-profit-de-messenger-pour-ameliorer-votre-architecture
  • Polytech Paris Sud (ehemals IFIPS) 2008: Projekt „Information Extraction from Texts“ – Dokumentenklassifizierung von François Yvon und Alexandre Allauzen, durchgeführt als Tutorium im Studienjahr 2007/2008 mit der Programmiersprache Perl unter der Leitung von Matthieu Beyou https://www.linkedin.com/in/matthieu-beyou-9a425a32/

Beispiele von Freunden zu EIT-Themen und mathematischen Modellen, die auf KI angewendet werden

Claude hat Verkaufsgespräche für immer verändert! (Kostenloser Skill) – Alexandra Spalato | KI-Automatisierung: https://www.youtube.com/watch?v=FuVIGGWwYKY

  • KI verständlich gemacht: Ein praktischer Leitfaden für PHP-Entwickler - Iana IATSUN - PHP Forum 2024: https://www.youtube.com/watch?v=u-yrK_-_p9g
  • Einbettungen in PHP: Symfony AI in der Praxis: https://speakerdeck.com/lyrixx/embeddings-symfony-ai-en-pratique
  • Stack Overflow-Tags – automatische Vorhersage mithilfe von Algorithmen des maschinellen Lernens – Marco Berta: https://www.youtube.com/watch?v=fFKXFDDjEJU
  • API Platform Conference 2025 - Gregory Planchat - L'Event Storming dans nos projets API Platform : https://www.youtube.com/watch?v=zyxsibA7by4
  • Hilfe! Ich soll KI einsetzen! – Drupal Camp Grenoble 2026 – Alexandre Balmes: https://speakerdeck.com/pocky/au-secours-on-me-demande-dutiliser-de-lia-drupal-camp-grenoble-2026
  • DeepMinds neue KI hat die Wissenschaft für immer verändert – Zwei-Minuten-Papiere: https://www.youtube.com/watch?v=Io_GqmbNBbY
  • Langflow-Modelle sind intelligent. Daten sind alles. Kontextreiche KI-Systeme mit unstrukturierten Daten entwickeln: https://www.youtube.com/watch?v=fNLUv6Pvc6w
  • Ich bin eine Legende: Hearthstone-Hacking mit maschinellem Lernen - Elie Bursztein, Celine Bursztein: https://elie.net/talk/i-am-a-legend Erzähl mir etwas über mich selbst, das ich noch nicht weiß – von Nathalie | Eine Stimme, die trägt: https://x.com/Bonzai_Star/status/2031432381471797589

Die Zukunft der KI aus der Sicht von Yann LeCun

Niemand ahnt, was Yann LeCun da gerade geschaffen hat – Grand Angle Nova: https://www.youtube.com/watch?v=P-wAr687qxg

  • Für Neugierige: Antrittsvorlesung von Yann LeCun – Deep Learning and Beyond: The New Challenges of AI – École nationale des ponts et chaussées: https://www.youtube.com/watch?v=Z208NMP7_-0 Woraus besteht Wissen? Von Arthur Sarrazin (https://www.linkedin.com/in/arthursarazin) auf https://srzarthur.substack.com/p/what-is-knowledge-made-of

Site

Network

Social

Darkwood 2026, alle Rechte vorbehalten