Self-Contained Systems

Der Self-Contained System (SCS)-Ansatz ist eine Architektur, die sich auf eine Aufteilung der Funktionalität in viele unabhängige Systeme konzentriert, wodurch das vollständige logische System zu einer Zusammenarbeit vieler kleinerer Softwaresysteme wird. Dies vermeidet das Problem großer Monolithen, die ständig wachsen und schließlich nicht mehr gewartet werden können. In den letzten Jahren haben wir seine Vorteile in vielen mittleren und großen Projekten gesehen.

Die Idee ist, ein großes System in mehrere kleinere, in sich geschlossene Systeme oder SCSs aufzuteilen, die bestimmten Regeln folgen.

Jedes SCS ist eine autonome Webanwendung. Für die Domäne des SCS sind alle Daten, die Logik zum Verarbeiten dieser Daten und der gesamte Code zum Rendern der Webschnittstelle im SCS enthalten. Ein SCS kann seine primären Anwendungsfälle eigenständig erfüllen, ohne auf die Verfügbarkeit anderer Systeme angewiesen zu sein.

Jedes SCS gehört einem Team. Das bedeutet nicht unbedingt, dass nur ein Team den Code ändern kann, aber das besitzende Team hat das letzte Wort darüber, was in die Codebasis einfließt, zum Beispiel durch Zusammenführen von Pull-Requests.

Die Kommunikation mit anderen SCS oder Drittsystemen erfolgt nach Möglichkeit asynchron. Insbesondere sollte auf andere SCS oder externe Systeme nicht synchron innerhalb des eigenen Anfrage/Antwort-Zyklus des SCS zugegriffen werden. Das entkoppelt die Systeme, reduziert die Auswirkungen von Ausfällen und unterstützt so die Autonomie. Das Ziel ist die zeitliche Entkopplung: Ein SCS soll auch dann funktionieren, wenn andere SCS zeitweise offline sind. Dies kann auch erreicht werden, wenn die Kommunikation auf technischer Ebene synchron ist, z. B. durch Replizieren von Daten oder Puffern von Anfragen.

Ein SCS kann eine optionale Dienst-API haben. Da das SCS über eine eigene Web-UI verfügt, kann es mit dem Benutzer interagieren – ohne einen UI-Dienst zu durchlaufen. Eine API für mobile Clients oder für andere SCS könnte jedoch immer noch nützlich sein.

Jeder SCS muss Daten und Logik enthalten. Um wirklich sinnvolle Features zu implementieren, werden beide benötigt. Ein SCS sollte Features selbst implementieren und muss daher beide enthalten.

Ein SCS sollte seine Funktionen für Endbenutzer über eine eigene Benutzeroberfläche nutzbar machen. Daher sollte der SCS keine gemeinsame Benutzeroberfläche mit anderen SCS haben. SCS können immer noch Verbindungen zueinander haben. Die asynchrone Integration bedeutet jedoch, dass der SCS auch dann funktionieren sollte, wenn die Benutzeroberfläche eines anderen SCS nicht verfügbar ist.

Um eine enge Kopplung zu vermeiden, sollte ein SCS keinen Geschäftscode mit anderen SCS teilen. Es kann in Ordnung sein, einen Pull-Request für einen SCS zu erstellen oder allgemeine Bibliotheken zu verwenden, z. Datenbanktreiber oder oAuth-Clients.

Um SCS robuster zu machen und die Entkopplung zu verbessern, kann die gemeinsame Infrastruktur minimiert werden. Z.B. eine gemeinsame Datenbank machen die Ausfallsicherheit und Skalierbarkeit der SCSs von der zentralen Datenbank abhängig. Aufgrund z.B. eine gemeinsam genutzte Datenbank mit separaten Schemas oder Datenmodellen pro SCS kann eine gute Alternative sein.