INNOQ hat im August 2026 einen Primer zu Self-contained Systems veröffentlicht, geschrieben von Johannes Seitz. Ich habe ihn mit einer klaren Frage im Kopf gelesen: Deckt sich das mit dem, was ich in meinen Vorträgen und im Java-Magazin-Artikel erzähle?

Kurze Antwort: ja, im Kern. Der Primer ist gut, kompakt und ehrlich in seinen Trade-offs. Es gibt aber drei Stellen, an denen ich anders gewichte. Die sind interessanter als die Übereinstimmungen, deshalb kommen sie hier ausführlicher.

Wo wir uns einig sind

Der Kern des Architekturstils ist identisch beschrieben: fachlicher Schnitt statt technischer Schichtung, jedes System mit eigener UI, eigener Geschäftslogik und eigener Datenhaltung, asynchrone Integration als Standard und synchrone Aufrufe nur als bewusst begründete Ausnahme.

Besonders gefreut hat mich der Abschnitt zur Datenfalle. Der Primer sagt deutlich, dass gemeinsam genutzte Daten als Schnittkriterium ein Anti-Pattern sind und dass es kein Stammdaten-System für „Kunde“ oder „Vertrag“ gibt. Dazu die Prozessfalle, also der Reflex, Systemgrenzen entlang der Schritte eines Flussdiagramms zu ziehen. Beides sind Fehler, die ich in Kundenprojekten regelmässig sehe. Dass der Primer Parnas und Information Hiding als Prüfkriterium für den Schnitt heranzieht, passt genau zu meiner Argumentation: Modularität ist ein Entwurfsthema, keine Deployment-Frage.

Auch das Fazit ist deckungsgleich mit meiner Position. Das Problem war nie der Monolith, sondern seine Tendenz zum unkontrollierten Wachstum. Stefan Tilkovs Satz „Wir lieben Monolithen, also lasst uns viele davon bauen“ bringt es auf den Punkt.

Und die Fehlerbilder beim Messaging sind sauber abgehandelt: Transactional Outbox, Idempotent Receiver, Dead Letter Queue, Durable Subscriptions. Wer in meinem Vortrag war, kennt das Beispiel mit den doppelt ausgelösten Lieferungen. Genau diese Klasse von Problemen ist im Primer benannt, samt Lösungsmuster.

Punkt 1: Der modulare Monolith fehlt als Zwischenschritt

Der Primer geht vom gewachsenen Monolithen ziemlich direkt zum ersten Carve-out. Er nennt zwar die Schwelle, ab der sich der Aufwand lohnt, nämlich wenn Abstimmung, Test und Deployment enorm geworden sind. Aber zwischen „grosser Monolith“ und „erstes eigenständiges System“ liegt für mich noch eine Stufe: der modulare Monolith.

Für einen grossen Teil der Geschäftsanwendungen, mit denen ich zu tun habe, ist ein sauber modularisierter Monolith mit Spring Modulith die pragmatische Wahl. Ein Deployable, eine Datenbank, aber klare Modulgrenzen, die auch geprüft werden. Damit bekommt man den wichtigsten Teil des Nutzens, nämlich den fachlichen Schnitt und die Kopplungskontrolle, ohne den Betrieb eines verteilten Systems zu bezahlen.

Self-contained Systems lohnen sich für mich dann, wenn mehrere Teams unabhängig entwickeln und deployen müssen. Das ist eine organisatorische Schwelle, keine technische. Wer sie noch nicht erreicht hat, kann seine Modulgrenzen im Monolithen üben und später herausschneiden. Der Primer beschreibt den Carve-out sehr gut, aber ein Kapitel davor fehlt mir die ehrliche Ansage: Vielleicht brauchst du noch gar keine verteilten Systeme.

Punkt 2: Die UI-Integration ist mir zu JavaScript-lastig

Das Kapitel zur UI-Integration beginnt richtig, mit Links, Transklusion, Server-side Includes und Edge Side Includes. Dann landet es bei Web Components, Angular Custom Elements und Module Federation.

Meine Umsetzungen sind server-seitiges Java. Vaadin rendert die Oberfläche, die Integration läuft über Links und Redirects, über Transklusion und über ein gemeinsames Design System. Das reicht in der Praxis erstaunlich weit. Der Primer erwähnt diese Wege, behandelt sie aber eher als Vorstufe zu den komponentenbasierten Ansätzen.

Was mir ganz fehlt, sind die ROCA-Prinzipien. Resource-oriented Client Architecture ist für SCS fast eine natürliche Ergänzung: sinnvolle URLs, serverseitig gerendertes HTML, Funktionsfähigkeit ohne JavaScript, kein geteilter Client-Zustand. Wer so baut, bekommt die lose Kopplung zwischen den Oberflächen fast geschenkt.

Bei Module Federation bin ich deutlich skeptischer als der Primer. Er benennt die Nachteile korrekt, also gemeinsame Laufzeitumgebung, geteilte Abhängigkeiten, eine proprietäre Library als Pflichtbestandteil der Makroarchitektur. Aber für mich ist das kein Trade-off mehr, sondern ein Widerspruch zum Stil. Man baut mit viel Aufwand Systeme, die unabhängig deploybar sind, und koppelt sie dann im Browser wieder aneinander. Wenn eine so enge Integration wirklich nötig ist, ist das für mich eher ein Hinweis, dass der fachliche Schnitt nicht stimmt.

Punkt 3: Single Sign-on verdient mehr als eine Randbemerkung

Authentifizierung und Autorisierung tauchen im Primer bei den Querschnittsstandards auf, und in der UI-Integration wird erwähnt, dass alle Frontends unter derselben Domain laufen müssen, damit ein geteiltes Session-Cookie funktioniert.

Aus meiner Projekterfahrung ist das eines der ersten Themen, über die man stolpert. Sobald ein Benutzer zwischen zwei Systemen wechselt und sich neu anmelden muss, ist das nahtlose Erlebnis dahin, und die schöne Architektur wird für die Fachabteilung zum Rückschritt. Ein gemeinsames Single Sign-on gehört für mich zusammen mit dem Design System zum Pflichtprogramm der Makroarchitektur, nicht in eine Fussnote. Genauso wie die Frage, wo die gemeinsame Navigation lebt. Der Primer diskutiert das immerhin am Ende, inklusive der unangenehmen Wahrheit, dass ein zentraler Rahmen einen Single Point of Failure erzeugt.

Ein Halbsatz mit Zukunft

An einer Stelle erwähnt der Primer, dass Coding Agents fehlende Spezialisierungen im Team teilweise abdecken können. Das ist ein Halbsatz, aber ein wichtiger.

Ein Self-contained System soll von einem kleinen Team von der Idee bis in den Betrieb verantwortet werden. Genau da liegt in der Praxis oft das Problem: Das Team hat keine eigene Datenbankkompetenz, keinen Testautomatisierer, niemanden für die Pipeline. Was mich daran interessiert, ist weniger die Geschwindigkeit beim Codieren als die Frage, welche Artefakte ein Team braucht, damit Agenten in einem fachlich abgegrenzten System sinnvoll arbeiten können. Ein SCS ist dafür ein fast idealer Zuschnitt: überschaubarer Kontext, eigene Datenbank, eigene Oberfläche, klare Schnittstellen nach aussen. Das ist ein eigener Artikel, aber es ist der Punkt, an dem sich Architektur und die Art, wie wir künftig entwickeln, treffen.

Fazit

Der Primer ist eine klare Leseempfehlung, besonders für Architektinnen und Architekten, die ihre Systemlandschaft neu schneiden müssen. Er ist ehrlich bei den Trade-offs, und die Kapitel zur Domänenarchitektur und zum Messaging sind die stärksten.

Wenn du aus der Java-Welt kommst und mit Spring Boot und einem server-seitigen UI-Framework arbeitest, lies das UI-Kapitel mit etwas Abstand. Und bevor du dein System zerlegst, stelle dir die Frage, ob du wirklich mehrere Teams hast, die unabhängig liefern müssen. Wenn nicht, fang mit sauberen Modulen in einem Deployable an.