Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
Kernaussagen
- Ein Self-contained System ist mehr als ein Microservice mit Web-Oberfläche: Johannes Seitz nennt es einen begrenzten Monolithen, Simon Martinelli eine Teilapplikation.
- Für Silvia Schreier ist die Laufzeitunabhängigkeit das zentrale Feature: Fallen alle anderen Systeme aus, erfüllt ein SCS seinen Job noch zu einem großen Teil.
- Eberhard Wolff stellt den fachlichen Schnitt über die Verfügbarkeit. Johannes sieht beides Hand in Hand, weil unabhängiger Betrieb auch unabhängiges Entwickeln und lokales Testen erleichtert-
- SCS gibt anders als Microservices eine Integrationspräferenz vor: Integration vermeiden, sonst so lose wie möglich, etwa per Link oder eingebettetem UI-Element.
- Das Spannende ist für Eberhard die Nicht-Vernetzung der Systeme; synchrone Aufrufe nur, wo es nicht anders geht.
- Für Eberhard ist kaum geteilte Infrastruktur ein weiches Kriterium. Simon teilt Datenbankinstanzen mit getrennten Schemas und Berechtigungen. Silvia sieht geteilte Kubernetes-Cluster als Risiko für Unabhängigkeit und Upgrades.
- In Banken und Versicherungen laufen nach Johannes Erfahrung etwa 80 Prozent der Integration über gemeinsam genutzte Datenbanken. Das verletzt Information Hiding wie ein direkter Zugriff auf Instanzvariablen.
- In fast jedem Unternehmen gibt es ein Bottleneck-SCS wie den Checkout, an dem jede Initiative hängt. Wo ein Feature umgesetzt wird, hängt auch von Auslastung, Lebenszyklus und Skills der Teams ab.
- Eine gemeinsame Navigation über Systemgrenzen ist machbar, aber nicht immer nötig. Designsystem, unveränderbare Deep Links und eingebettete UI-Komponenten decken den Bedarf nach einem einheitlichen Design ab.
- SCS ist kein Qualitätssiegel: Der Sweet Spot liegt wie bei Domain-driven Design bei hoher fachlicher Komplexität und mehreren Teams, einzelne Regeln lassen sich auch anderswo übernehmen
- Code-Duplikation über viele Teams kann ein Problem sein. Designsystem, geteilte Bibliotheken, Archetypes und ein Architektur-Board mit ADRs halten sie klein.
- Alle vier erwarten, dass Self-contained Systems in zehn Jahren noch relevant sind, auch weil der begrenzte Kontext KI-getriebener Entwicklung hilft.
Behandelte Fragen
- Sind Self-contained Systems Microservices mit eigener Web-Oberfläche?
- Was ist wichtiger: getrennte Verfügbarkeit oder ein guter fachlicher Schnitt?
- Warum ist die Nicht-Vernetzung spannender als die Vernetzung der Systeme?
- Wie viel geteilte Infrastruktur, etwa eine gemeinsame Datenbank, ist vertretbar?
- Warum integrieren so viele Unternehmen über gemeinsame Datenbanken, und was hat das mit Information Hiding zu tun?
- Wie geht man mit einem Team um, an dem jede Initiative hängt?
- Braucht es eine gemeinsame Navigation über alle Systeme?
- Wie behandelt man ein System, das nur Daten austauscht und keine Oberfläche hat?
- Wie verhindert man Code-Duplikation und Inkonsistenz bei mehr als 20 Teams?
- Wäre ein Monolith die bessere Wahl?
- Reden wir in zehn Jahren noch über Self-contained Systems?
Glossar
- Self-contained System (SCS): Fachlich abgegrenztes System mit eigener UI, Logik und Datenhaltung, das einem Team gehört und möglichst unabhängig von anderen Systemen läuft
- Laufzeitunabhängigkeit: Ein System erfüllt seine Aufgabe weitgehend auch dann, wenn andere Systeme ausgefallen sind
- UI-Integration: Systeme verbinden sich über Links oder eingebettete UI-Elemente statt über Backend-Aufrufe
- Kaum geteilte Infrastruktur: SCS-Regel, nach der Systeme möglichst wenig Infrastruktur wie Datenbanken oder Cluster teilen
- Information Hiding: Prinzip, Implementierung und Datenmodellierung hinter einer Schnittstelle zu verbergen, damit sie sich ändern lassen
- Bottleneck-SCS: System, dessen Team an fast jeder Initiative beteiligt ist, etwa der Checkout im E-Commerce
- Makro- und Mikroarchitektur: Regeln, die für alle Systeme gelten, und Entscheidungen, die jedes Team innerhalb seines Systems selbst trifft
- Designsystem: Gemeinsame Bausteine und Gestaltungsregeln, die Oberflächen verschiedener Systeme einheitlich aussehen lassen
- Reverse-Conway-Manöver: Teams so organisieren, dass die gewünschte Architektur entsteht
- Sollbruchstelle: Vorab eingeplante Grenze in einem Monolithen, an der er sich später auf Teams und Systeme aufteilen lässt
Erwähnte Technologien und Werke
- Self-contained Systems: Website zum Architekturansatz, auf der Eberhard Wolff vor über zehn Jahren den ersten Commit gemacht hat
- Artikel von Phillip Ghadir und Stefan Tilkov: Etwa 15 Jahre alter Ursprung der Self-contained Systems, auf der SCS-Website verlinkt
- Balancing Coupling in Software Design: Buch von Vlad Khononov, im Chat empfohlen
- Team Topologies: Ansatz, aus dem Johannes den Begriff Stream-aligned Team übernimmt
- Testcontainers: Bibliothek, mit der Teams laut Simon ihre Systeme mit generierten Testdaten lokal testen
- Kubernetes: Container-Plattform, deren geteilte Cluster in der Folge als Risiko für die Unabhängigkeit gelten
- Hibernate: Java-Persistenz-Framework, dessen durchgängige Mappings laut Simon allen Modulen dieselbe Sicht auf die Daten geben
- iSAQB: Verband, nach dessen Lehrplan Johannes Architekturtrainings gibt