SOA-orientierte Ansätze (Serviceorientierte Architekturen) sind tendenziell datengetriebener bzw. datenbasierter als klassische monolithische Systeme – allerdings nicht im Sinne von „mehr Datenverarbeitung“, sondern im Hinblick auf Architekturprinzipien und Systemverhalten.
1. Lose Kopplung & Datenübertragung
- SOA Systeme bestehen aus modularen, unabhängigen Services, die über definierte Schnittstellen (APIs, Protokolle wie SOAP oder REST) miteinander kommunizieren.
- Diese Kommunikation erfolgt typischerweise datenzentriert – Services tauschen strukturierte Datenformate (z. B. XML, JSON) aus, um Informationen weiterzugeben.
- Monolithen hingegen haben oft direkten Speicherzugriff auf zentrale Datenstrukturen, ohne dass die Daten explizit über Schnittstellen fließen müssen.
👉 Fazit: In SOA ist die Datenstruktur entscheidend für die Interaktion, was einen datengetriebenen Charakter verstärkt.
2. Service Contracts & Datenmodelle
- In SOA definieren sogenannte Service Contracts exakt, welche Datenformate und -modelle zwischen Services erwartet werden.
- Die Architektur wird dadurch stark von Datenflüssen und -strukturen geprägt, um Interoperabilität zu gewährleisten.
Monolithen hingegen operieren oft mit einem gemeinsamen Datenmodell im Speicher – ohne explizite Verträge, da alles „im Haus“ läuft.
3. Datenzentrierte Geschäftslogik
- In SOA wird die Geschäftslogik um die Daten herum strukturiert, z. B. „Der Service X erwartet Objekt Y mit Attributen A, B, C“.
- Es entstehen oft Daten-Pipelines, z. B. für Kundenprozesse, in denen Informationen zwischen Services fließen.
Monolithen haben typischerweise eng verknüpfte Logik und Daten, oft innerhalb eines riesigen Codes und eines zentralen Datenbankschemas.
4. Event-getriebene Architekturen als Ergänzung
- Moderne SOA-Systeme (z. B. mit Microservices oder Event-driven Architecture) sind oft stark daten- und ereignisgesteuert, d. h. Services reagieren auf Datenänderungen (Events), ohne direkte Steuerung durch zentrale Komponenten.