SCS in der Realität

Self-Contained Systems (SCS) sind mehr als Deployment-Einheiten. Sie sind Organisationsgrenzen — und sie funktionieren nur, wenn man Conway’s Law ernst nimmt.

Was SCS bedeutet

Ein SCS besitzt:

• Seine eigene UI (als Micro-Frontend)
• Seinen eigenen API-Layer
• Seinen eigenen Domänen-Service
• Seine eigene Datenhaltung (Datenbank, Message Queue)
• Sein eigenes Deployment

Kein anderes SCS greift direkt auf seine Daten zu. Kommunikation läuft über Events oder HTTP-APIs.

Wo es schmerzt

Shared State: Der eingeloggte User ist kein klarer SCS-Besitzer. Auth-Kontext muss verteilt werden — über Token, über ein Auth-SCS, über ein shared Keycloak.

Cross-SCS-Workflows: Wenn ein Workflow über SCS-Grenzen geht (Task erstellen → User benachrichtigen → Dashboard aktualisieren), braucht man Event-Choreographie oder Orchestrierung.

Shared UI: Ein konsistentes Design-System zu haben und trotzdem unabhängig zu deployen erfordert Versionierungsdisziplin.

In Taskly

6 SCS, jedes mit eigenem Remote + API + Service. Gemeinsame Shell (taskly) als Host. Keycloak als zentraler Auth-Provider. RabbitMQ für async Events zwischen SCS.

Die Grenze zwischen „sauber getrennt” und „zu wenig integriert” ist permanent aktiv.