Wann SCS?
Ein Self-Contained System (SCS) ist eine Einheit aus UI, API, Service und Datenhaltung — alles unter einem Deployment-Dach. Es ist die Antwort auf die Frage: Wie weit gehen wir mit der Isolation?
Wann SCS die richtige Wahl ist
Abschnitt betitelt „Wann SCS die richtige Wahl ist“- Team-Autonomie als Ziel: Das Team kann end-to-end deployen, ohne andere Teams um Erlaubnis zu fragen.
- Domänen-Isolation: Die Domäne (Tasks, Members, Dashboard) ist klar abgegrenzt und hat wenig Cross-Domain-Interaktion.
- Unterschiedliche Entwicklungs-Geschwindigkeiten: Manche Domänen ändern sich täglich, andere monatlich. SCS entkoppelt diese Zyklen.
Was SCS kostet
Abschnitt betitelt „Was SCS kostet“- Infrastruktur-Overhead: Jedes SCS braucht eigene Datenbank, eigene Message-Queue-Konfiguration, eigenes Keycloak-Realm oder -Client.
- Cross-SCS-Workflows: Wenn Use-Cases SCS-übergreifend sind, braucht man Choreographie oder Orchestrierung.
- Shared State: Auth-Kontext, Benachrichtigungen, globale Einstellungen — irgendwer muss diese Querschnitt-Themen lösen.
Die Grenze zu Microservices
Abschnitt betitelt „Die Grenze zu Microservices“SCS enthält das Frontend. Microservices (ohne SCS-Konzept) trennen Frontend und Backend separat. SCS ist die radikalere Isolation — mit dem Vorteil, dass UI und Backend derselben Domäne zusammen entwickelt und deployed werden.
In Taskly
Abschnitt betitelt „In Taskly“6 SCS (Tasks, Todos, Members Directory, Dashboard, Project Assessment, Activity Stream) + Host-Shell. Jedes SCS eigene Remote-App, eigene API, eigener Service.