Self-Contained Systems (SCS)

Einleitung

Self-Contained Systems (SCS) schneiden ein Produkt in vertikale, autonome Systeme, die jeweils:

eine eigene UI
eigene Business-Logik
eigene Datenhaltung
eigene Deployment-Pipeline

besitzen.

SCS priorisiert:

Team-Autonomie durch vertikale Fachschnitte.

Es ist ein Gegenentwurf zu:

zentralisierten Monolithen
extrem feingranularen Microservice-Landschaften

Einordnung

SCS ist ein Makro-Architekturstil.

Es definiert:

Systemstruktur
Ownership
Deployment-Grenzen
Integrationsmechanik

SCS steht zwischen:

Modularer Monolith (ein Deployment)
Microservices (feingranulare Services)

Grundprinzip

Kernaussage:

Vertikale Systeme
Klare Fachverantwortung
Integration bevorzugt asynchron

Charakteristika

1️⃣ Vertikale Slice-Struktur

Ein SCS enthält:

Frontend
Backend
Daten

für eine klar definierte Geschäftsfähigkeit.

2️⃣ Eigene Persistenz

Keine Shared Database als Integrationsmechanismus
Klare Datenhoheit pro SCS
Datenzugriff nur über definierte Schnittstellen

3️⃣ Unabhängige Deployments

Jedes SCS:

kann eigenständig released werden
kann unabhängig skalieren
kann unabhängig degradieren

Statt:

tiefer Runtime-Komposition

Oft:

Navigation zwischen SCS
klare URL-Struktur
lose UI-Kopplung

5️⃣ Minimale synchrone Kopplung

Integration bevorzugt:

Events
Verträge
APIs mit klarer Verantwortung

Nicht:

tiefe synchrone Call-Chains

Vorteile

Hohe Team-Autonomie
Klare Ownership-Grenzen
Geringere Komplexität als sehr feine Microservices
Gute Skalierbarkeit entlang von Domänen
Starke fachliche Kohärenz

Nachteile / typische Fallstricke

Duplikation von Querschnittsfunktionen
Inkonsistente UX ohne Design-Governance
Schwierige End-to-End-Prozesse über mehrere SCS
Event-Governance notwendig
Potenzielle Dateninkonsistenz bei schlechter Integration

SCS vs. Microservices

	SCS	Microservices
Granularität	grob (fachlich)	fein (technisch/fachlich)
UI	pro System	meist getrennt
Deployment	pro SCS	pro Service
Komplexität	moderat	hoch bei vielen Services
Typischer Fokus	Team-Autonomie	Skalierbarkeit & Resilienz

SCS sind oft:

Weniger feingranular, aber organisatorisch stabiler.

Wann passt SCS gut?

Mehrere produktnahe Teams
Klare fachliche Domänen
Wunsch nach vertikaler Ownership
Migration aus Monolith
UI-getriebene Systeme

Wann weniger geeignet?

Sehr kleines Team
Stark transaktionale Gesamtprozesse
Extrem hohe technische Skalierung pro Funktion
Sehr strikte globale UX-Vorgaben

Typische Kombinationen

Bounded Contexts (DDD)
BFF pro SCS
Event-Driven Integration
Strangler Fig für Migration
Modularer Monolith als Startpunkt

Organisatorische Realität

SCS funktioniert nur, wenn:

Teams langfristig Ownership übernehmen
Datenhoheit respektiert wird
Integration diszipliniert erfolgt
Plattform-Grundlagen vorhanden sind

Ohne Ownership entsteht:

Verteilter Monolith mit UI.

Fazit

SCS ist ein Makro-Architekturstil, der:

vertikale Fachsysteme
klare Deployment-Grenzen
Team-Autonomie

in den Mittelpunkt stellt.

Es ist oft:

stabiler als extreme Microservice-Granularität
realitätsnäher in mittleren Organisationen
ein pragmatischer Evolutionspfad aus dem Monolithen

Einleitung​