Die Softwarearchitektur hat sich in den letzten drei Jahrzehnten erheblich weiterentwickelt. Während Microservices lange Zeit als das Nonplusultra modularer Systeme galten, stellt sich zunehmend die Frage, ob dieser Ansatz für alle Anwendungsfälle optimal ist. Self-Contained Systems bieten eine vielversprechende Alternative, die viele Herausforderungen traditioneller Microservice-Architekturen elegant löst.

Die Evolution der Softwarearchitektur: Vom Monolithen zu verteilten Systemen

Der Weg von Mainframes zu modernen Architekturen

Die Reise der Softwarearchitektur begann in den 1990er Jahren mit Mainframe-Systemen und Client-Server-Anwendungen. Mit der Einführung von J2EE im Jahr 1999 vollzog sich ein bedeutender Wandel: Unternehmen migrierten von COBOL-basierten Mainframe-Anwendungen zu Java-basierten Web-Anwendungen.

Diese Transformation ermöglichte erstmals die Entwicklung komplexer Webanwendungen, wie beispielsweise Online-Ticketing-Systeme für Bahnunternehmen. Doch mit der Zeit entstanden neue Herausforderungen: Die Anwendungen wurden zu "Big Balls of Mud" - schwer wartbare, chaotisch strukturierte Systeme ohne klare Modularisierung.

Das Microservices-Paradigma und seine Fallstricke

Netflix war einer der frühen Pioniere und Popularisierer des Microservices-Konzepts und begann seine Transformation bereits um 2008-2009. Dieser Ansatz versprach Skalierbarkeit und Modularität, brachte jedoch eigene Probleme mit sich:

Häufige Fehlinterpretationen von Microservices:

• Entwicklung zu kleiner "Nanoservices" statt angemessen dimensionierter Services
• Unternehmen mit drei Entwicklern, die 20 Microservices betreuen
• Vernachlässigung der UI-Integration
• Entstehung verteilter "Big Balls of Mud"

Modularity First: Das Fundament erfolgreicher Architekturen

Die Bedeutung der Modularisierung

Bevor über Verteilung nachgedacht wird, muss die grundlegende Modularisierung stimmen. David Parnas legte bereits 1972 in seiner wegweisenden Arbeit über 'Information Hiding' die theoretischen Grundlagen für effektive Modularisierung fest. Diese Erkenntnis gilt heute mehr denn je.

Domain Driven Design als Basis

Bounded Contexts aus dem Domain Driven Design bieten einen natürlichen Ansatz zur Systemaufteilung. Sie folgen den Geschäftsdomänen und reduzieren die notwendige Kommunikation zwischen Teams, da verschiedene Fachbereiche oft unabhängig voneinander arbeiten können.

Self-Contained Systems: Ein ganzheitlicher Ansatz

Definition und Kernprinzipien

Self-Contained Systems (SCS) sind ein Architekturstil, der maßgeblich von deutschen Technologieunternehmen und der Community um innoQ geprägt wurde. Im Gegensatz zu Microservices umfassen SCS nicht nur die Backend-Logik, sondern auch die Benutzeroberfläche - von der UI bis zur Datenhaltung.

Hauptmerkmale von Self-Contained Systems:

• Vollständige vertikale Kapselung (UI + Backend + Datenbank)
• Autonome Deployments
• Minimale Kommunikation zwischen Systemen
• Größere Services im Vergleich zu Microservices
• Fokus auf Geschäftsdomänen

Kommunikation ohne Abhängigkeiten

Ein wesentlicher Unterschied zu Microservices liegt in der Kommunikationsstrategie: Self-Contained Systems vermeiden synchrone Kommunikation im Regelbetrieb. Während Migrationsphasen können temporäre Kopplungen, wie gemeinsame Datenbanken, notwendig sein. Stattdessen erfolgt die Integration über:

• Hyperlinks zwischen Anwendungen (wie bei Amazon's Checkout-Prozess)
• Asynchrone Ereignisse für notwendigen Datenaustausch
• Datenreplikation für Read-Only-Zugriffe

Vorteile von Self-Contained Systems gegenüber Microservices

Reduzierte Komplexität

SCS reduzieren viele typische Probleme verteilter Systeme:

• Cascade-Failures zwischen Services
• Weniger Netzwerk-Latenz
• Einfacheres Monitoring und Debugging
• Reduzierter Bedarf an Resilience-Patterns

Team-Autonomie und Full-Stack-Entwicklung

Jedes Team besitzt einen vollständigen vertikalen Schnitt durch die Anwendung. Dies ermöglicht:

• Direkte Benutzer-Feedback-Schleifen
• Vollständige Verantwortung für eine Geschäftsdomäne
• Technische Entscheidungsfreiheit pro System
• Effiziente Full-Stack-Entwicklung

Skalierbarkeit in alle Richtungen

Self-Contained Systems skalieren nicht nur nach oben und außen, sondern auch nach unten - bis auf null. Dies ist besonders relevant für Geschäftsanwendungen, die außerhalb der Arbeitszeiten nicht benötigt werden.

Praxisbeispiel: ERP-System-Modernisierung

Ausgangssituation: Von Eclipse RCP zu modernen Web-Anwendungen

Ein praktisches Beispiel zeigt die Migration eines Eclipse RCP-basierten ERP-Systems zu Self-Contained Systems. Das ursprüngliche System war ein typischer Monolith, der über 15 Jahre gewachsen war und modernisiert werden musste.

Bounded Contexts im ERP-Umfeld

Die Aufteilung folgte natürlichen Geschäftsprozessen:

• Beschaffung: Lieferantenmanagement und Einkauf
• Verkauf: Kundenbeziehungen und Auftragsabwicklung
• Logistik: Lager- und Transportmanagement
• Finanzen: Buchhaltung und Zahlungsverkehr

Technische Umsetzung mit Datenreplikation

Jedes Self-Contained System erhält:

• Eine Write-Datenbank für eigene Daten
• Eine Read-Only-Datenbank mit replizierten Fremddaten
• Event-basierte Kommunikation für Geschäftsprozesse
• Einheitliche UI-Komponenten basierend auf Vaadin

Migration Strategy: Strangler Fig Pattern

Schrittweise Ablösung des Legacy-Systems

Die Migration erfolgt nach dem Strangler Fig Pattern - einem bewährten Ansatz für große Modernisierungsprojekte:

1. Parallelbetrieb von altem und neuem System
2. Schrittweise Migration einzelner Bounded Contexts
3. Temporäre Integration über gemeinsame Datenbanken
4. Vollständige Ablösung des Legacy-Systems

Herausforderungen bei der Modernisierung

Modernisierungsprojekte sind primär Organisationsprojekte, nicht nur Technologieprojekte. Typische Herausforderungen:

• Implementierung neuer Features in beiden Systemen
• Verfügbarkeit erfahrener Teammitglieder
• Geschäftliche Anforderungen während der Migration
• Projektdauer von mehreren Jahren

Vergleich: Self-Contained Systems vs. Microservices

Technische Unterschiede

Wann welcher Ansatz sinnvoll ist

Self-Contained Systems eignen sich für:

• Geschäftsanwendungen mit klaren Domänen-Abgrenzungen
• Teams von 3-7 Personen pro System
• Projekte mit Full-Stack-Anforderungen
• Modernisierungsprojekte

Microservices sind optimal bei:

• Hochfrequentierten, skalierbaren Web-Services
• Spezialisierten Backend-Teams
• API-First-Strategien
• Cloud-nativen Anwendungen

Best Practices für Self-Contained Systems

Architekturprinzipien

1. Bounded Context First: Geschäftsdomänen definieren die Systemgrenzen
2. UI-Ownership: Jedes Team besitzt seine komplette Benutzeroberfläche
3. Autonomous Deployment: Unabhängige Releasefähigkeit aller Systeme
4. Event-Driven Integration: Asynchrone Kommunikation bevorzugen
5. Shared Nothing: Keine geteilten Datenbanken oder Services

Technische Empfehlungen

• Einheitliche Technologie-Stacks für vereinfachte Wartung
• Design Systems für konsistente Benutzeroberflächen
• Contract-Driven Development für Datenreplikation
• Link-Datenbanken für systemübergreifende Referenzen
• Monitoring und Observability auf System-Ebene

Herausforderungen und Lösungsansätze

Eventual Consistency bewältigen

Self-Contained Systems arbeiten mit eventual consistency - Daten sind nicht sofort überall verfügbar. In vielen Geschäftsdomänen ist dies jedoch unproblematisch:

• Stammdaten ändern sich selten und können repliziert werden
• Geschäftsprozesse haben natürliche Wartezeiten
• Benutzer-Workflows tolerieren kurze Verzögerungen

UI-Integration ohne Microfrondends

Statt komplexer Microfrontend-Architekturen nutzen SCS einfache Ansätze:

• Hyperlinks zwischen Anwendungen
• Einheitliche Design Systems
• Single Sign-On für nahtlose Benutzererfahrung
• Gemeinsame Navigation über alle Systeme

Zukunft der modularen Architekturen

Self-Contained Systems bieten einen pragmatischen Mittelweg zwischen monolithischen Anwendungen und hochverteilten Microservice-Architekturen. Sie adressieren reale Geschäftsanforderungen und reduzieren gleichzeitig die Komplexität verteilter Systeme.

Die Wahl der richtigen Architektur hängt letztendlich von den spezifischen Anforderungen ab: Teamgröße, Geschäftsdomäne, Skalierungsanforderungen und organisatorische Struktur. Self-Contained Systems beweisen jedoch, dass modulare Architekturen nicht zwangsläufig komplex sein müssen.

Fazit

Self-Contained Systems stellen eine ausgereifte Alternative zu traditionellen Microservice-Architekturen dar. Sie kombinieren die Vorteile modularer Systeme mit der Einfachheit geschäftsorientierten Denkens. Für viele Unternehmensanwendungen bieten sie eine optimale Balance zwischen Autonomie, Wartbarkeit und Entwicklungsgeschwindigkeit.

Der Erfolg von Self-Contained Systems liegt in ihrer Fokussierung auf Geschäftsdomänen statt technischer Abgrenzungen. Dies führt zu natürlicheren Systemgrenzen, effizienteren Teams und letztendlich zu besserer Software, die echten Geschäftswert liefert.

Häufig gestellte Fragen (FAQ)

Wie unterscheiden sich Self-Contained Systems von Modulithen?

Self-Contained Systems sind physisch getrennte Anwendungen mit eigenen Datenbanken und Deployments, während Modulithen logisch getrennte Module innerhalb einer einzigen Anwendung darstellen. SCS bieten echte Deployment-Autonomie und technische Vielfalt, Modulithen hingegen vereinfachen die Entwicklung bei kleineren Teams.

Welche Teamgröße ist optimal für Self-Contained Systems?

Die ideale Teamgröße liegt bei 3-7 Personen pro Self-Contained System, einschließlich Entwicklern, Testern und einem Product Owner. Diese Größe ermöglicht effiziente Kommunikation und vollständige Ownership über eine Geschäftsdomäne, ohne die Komplexität zu groß werden zu lassen.

Können Self-Contained Systems mit bestehenden Microservices kombiniert werden?

Ja, eine hybride Architektur ist möglich und oft sinnvoll. Self-Contained Systems können interne Microservices für spezialisierte Funktionen nutzen oder externe Microservices als APIs konsumieren. Wichtig ist dabei, die Autonomie der Self-Contained Systems zu bewahren und synchrone Abhängigkeiten zu minimieren.