Welche Architektur passt?

Die passende Architektur ist selten die beeindruckendste.

Sie ist die, deren Kosten zu deinem Problem passen.

Nicht jede Anwendung braucht Microfrontends, Microservices, Event-Streaming, Modulith, CQRS, BFFs, API-Gateways und drei verteilte Teams mit Conway-Diagramm an der Wand.

Aber nicht jede Anwendung bleibt eine einfache Todo-App.

Und genau da beginnt Architektur.

Nicht bei der Frage:

„Was ist modern?“

Sondern bei der deutlich unbequemeren Frage:

„Welche Komplexität haben wir wirklich — und welche Komplexität kaufen wir uns gerade nur aus Nervosität ein?“

Der Mythos: Wir wählen Architektur nach Zielbild

Ein beliebter Satz in Projekten lautet:

„Wir bauen es gleich richtig.“

Das klingt vernünftig.

Bis man merkt, dass „richtig“ oft bedeutet:

• wie auf der letzten Konferenz gesehen,
• wie beim großen Tech-Unternehmen im Blog beschrieben,
• wie das Tooling es gerade sehr überzeugend verkaufen möchte,
• oder wie die Architektur aussehen würde, wenn das Produkt bereits fünf Jahre gewachsen wäre.

Das Problem: Architektur ist keine Wunschliste.

Architektur ist eine Wette.

Eine Wette darauf, wo sich ein System verändern wird.
Eine Wette darauf, welche Teile unabhängig bleiben müssen.
Eine Wette darauf, welche Teams welche Verantwortung tragen können.
Eine Wette darauf, welche Komplexität der Betrieb wirklich beherrscht.

Und wie bei jeder Wette kann man danebenliegen.

Nur ist die Strafe bei Architektur meistens nicht ein verlorener Einsatz, sondern ein System, das nach sechs Monaten aussieht, als hätte jemand Enterprise-Patterns in eine Kaffeemaschine geschüttet.

Architektur beantwortet Probleme — und erzeugt neue

Keine Architekturform ist kostenlos.

Ein Monolith ist nicht automatisch schlecht.
Ein Modulith ist nicht automatisch altmodisch.
Microfrontends sind nicht automatisch flexibel.
Microservices sind nicht automatisch skalierbar.
Multi-Tenant ist nicht automatisch nur ein Feld tenantId.
Cross-Platform ist nicht automatisch „responsive machen wir mit CSS“.

Jede Architektur beantwortet bestimmte Probleme.

Und jede bringt neue Probleme mit.

Das ist kein Fehler. Das ist der Deal.

Architekturentscheidung	Beantwortet typischerweise	Erzeugt typischerweise
Einfacher Monolith	schnelle Lieferung, geringe Betriebskosten, einfache Konsistenz	wachsende Kopplung, wenn Grenzen fehlen
Modularer Monolith / Modulith	klare fachliche Grenzen ohne verteilten Betrieb	Disziplin bei Modulschnitten und Abhängigkeiten
Microfrontends	unabhängige Frontend-Teams und Deployments	Runtime-Komplexität, Integrationskosten, UX-Konsistenzprobleme
Self-contained Systems	fachlich autonome Systeme inklusive UI, API, Daten	Plattform-, Observability- und Betriebsaufwand
Microservices	unabhängige Services, Skalierung, technische Entkopplung	verteilte Daten, Netzwerkeffekte, Fehlerbilder, Betrieb
Multi-Tenant	Mandantenfähigkeit, Datenisolation, Produktvarianten	Berechtigungen, Datenmodellierung, Tests, Migrationen
Cross-Platform / Multi-UI	mehrere Clients und Nutzungskontexte	API-Design, State-Modelle, Design-Systeme, Release-Koordination

Die Frage ist also nicht:

„Welche Architektur ist gut?“

Die Frage ist:

„Welche Probleme müssen wir lösen — und welche neuen Probleme können wir uns leisten?“

Die einfache Todo-App verdient einfache Architektur

Die Todo-App wird in Architekturgesprächen gerne missbraucht.

Entweder als Beweis, dass alles trivial ist:

„Ist doch nur CRUD.“

Oder als Spielplatz, auf dem man Microservices, Event Sourcing, CQRS, DDD, Kafka, Kubernetes und drei Frontend-Layer demonstriert.

Beides ist Quatsch.

Eine einfache Anwendung verdient einfache Architektur.

Das ist keine Geringschätzung. Das ist Respekt vor dem Problem.

Wenn eine Anwendung fachlich überschaubar ist, von einem kleinen Team gebaut wird, wenig Integrationsdruck hat, keine komplexen Rollenmodelle braucht und mit einem gemeinsamen Deployment gut leben kann, dann ist ein sauber strukturierter Monolith oft völlig ausreichend.

Vielleicht sogar die beste Lösung.

Nicht, weil Monolithen magisch gut sind.

Sondern weil sie wenig Betriebsaufwand erzeugen, einfache lokale Entwicklung ermöglichen, Datenkonsistenz nicht über Netzwerkgrenzen verteilen und Teams nicht zwingen, zuerst eine Plattform zu bauen, bevor das Produkt überhaupt existiert.

Ein schlechter Monolith ist schlecht.

Ein einfacher Monolith mit klarer Struktur ist eine Stärke.

Der Unterschied liegt nicht im Namen.

Der Unterschied liegt in den Grenzen.

Wenn die Anwendung wächst

Irgendwann reicht „wir packen das da noch rein“ nicht mehr.

Das passiert selten an einem dramatischen Tag.

Es passiert schleichend.

Erst wird ein Feature in drei Komponenten verteilt.
Dann hängt ein Dialog an einem Store, der eigentlich schon fünf andere Use Cases bedient.
Dann kennt das Template plötzlich API-Details.
Dann werden Berechtigungen an Stellen geprüft, an denen niemand mehr damit gerechnet hat.
Dann braucht eine Änderung an „Kunde bearbeiten“ Anpassungen in fünf Bereichen, die laut Jira eigentlich nichts miteinander zu tun haben.

Willkommen im Architektur-Alltag.

Ab diesem Punkt wird nicht automatisch eine größere Architektur nötig.

Aber eine bewusstere.

Wichtiger werden dann:

• fachliche Feature-Schnitte,
• klare Module,
• Facades,
• explizite Boundaries,
• stabile ViewModels,
• saubere Stores,
• Tests an den richtigen Stellen,
• Abhängigkeitsregeln,
• nachvollziehbare Datenflüsse,
• und die Frage, wer fachlich wofür verantwortlich ist.

Das ist der Moment, in dem Architektur beginnt, weniger nach Ordnerstruktur und mehr nach Änderbarkeit zu riechen.

Der Modulith: der unterschätzte Zwischenraum

Zwischen „alles in einem Topf“ und „alles über Netzwerkgrenzen verteilen“ liegt ein Bereich, der in vielen Projekten zu wenig Aufmerksamkeit bekommt:

Der Modulith.

Ein Modulith ist kein Monolith mit hübscheren Ordnernamen.

Die Idee ist: Ein System bleibt gemeinsam deploybar, aber intern klar modularisiert. Fachliche Bereiche haben definierte Grenzen, Abhängigkeiten werden kontrolliert, technische und fachliche Verantwortlichkeiten sind sichtbar.

Das kann sehr viel bringen.

Man bekommt viele Vorteile klarer Architekturgrenzen, ohne sofort die vollen Kosten verteilter Systeme einzukaufen.

Kein Service-Mesh.
Keine verteilten Transaktionen.
Keine zehn Deployments für eine kleine fachliche Änderung.
Keine Debugging-Safari durch fünf Container, drei Logs und ein Dashboard, das nur sagt: „Irgendwas ist rot.“

Ein Modulith ist besonders interessant, wenn:

• die Domäne wächst,
• ein Team oder mehrere Teams klare fachliche Bereiche brauchen,
• gemeinsame Deployments noch akzeptabel sind,
• Datenkonsistenz wichtig bleibt,
• der Betrieb schlank bleiben soll,
• und man trotzdem verhindern möchte, dass das System innerlich zu Brei wird.

Der Modulith ist damit oft kein Rückschritt.

Er ist häufig die Architektur, die viele Systeme eigentlich gebraucht hätten, bevor jemand „Microservices“ gesagt hat.

Ein eigener Detailartikel dazu lohnt sich.

Microfrontends: flexibel klingt teuer

Microfrontends klingen erstmal wunderbar.

Unabhängige Teams.
Unabhängige Deployments.
Eigene Release-Zyklen.
Klare Produktbereiche.
Technologische Freiheit.
Weniger Abstimmung.

In echten passenden Kontexten ist das wertvoll.

Zum Beispiel, wenn mehrere Teams an klar getrennten Fachbereichen arbeiten, verschiedene Produktlinien existieren, Deployments unabhängig passieren müssen oder einzelne Frontend-Teile organisatorisch wirklich eigenständig verantwortet werden.

Aber Microfrontends lösen keine schlechten Grenzen.

Sie machen schlechte Grenzen nur sichtbarer.

Vorher war die Kopplung im Code unangenehm.
Danach ist sie zusätzlich in Runtime, Routing, Shared Dependencies, Auth, Styling, Design-System, API-Verträgen, Build-Pipelines und Deployment sichtbar.

Glückwunsch. Das Problem hat jetzt mehr Orte, an denen es brennen kann.

Microfrontends sind kein Reparaturset für eine unklare Domäne.

Wenn nicht klar ist, wem ein Feature gehört, welche Daten geteilt werden dürfen, welche UI-Zustände gemeinsam sind und wie fachliche Verantwortung geschnitten ist, dann hilft auch Module Federation nicht.

Dann hat man keinen Architekturgewinn.

Dann hat man verteilte Unklarheit.

Self-contained Systems: Autonomie ist mehr als ein eigener Build

Self-contained Systems gehen noch einen Schritt weiter.

Ein fachlicher Bereich besitzt nicht nur ein Stück Frontend, sondern typischerweise auch API, Datenhaltung, Geschäftslogik, Deployment und Betrieb. Die Idee ist starke fachliche Autonomie.

Das kann sinnvoll sein, wenn Fachbereiche wirklich eigenständig liefern, ändern und betreiben sollen.

Nicht nur auf dem Papier.

Sondern mit echten Teams, echter Verantwortung, echtem Betrieb und echten Grenzen.

Ein Self-contained System ist attraktiv, wenn:

• fachliche Domänen klar getrennt sind,
• Teams Ende-zu-Ende-Verantwortung tragen,
• Releases unabhängig erfolgen müssen,
• Datenhoheit pro Bereich wichtig ist,
• unterschiedliche Anforderungen an Betrieb oder Skalierung bestehen,
• und Integration bewusst über definierte Verträge laufen soll.

Aber zu früh eingesetzt entsteht schnell Plattform-Zirkus.

Dann baut man nicht mehr ein Produkt, sondern beschäftigt sich mit Shells, Gateways, Auth-Konzepten, Observability, Deployment-Matrizen, Vertragsversionierung, lokalen Entwicklungsumgebungen und der Frage, warum der eine Bereich im Preview geht und der andere nur auf dem Rechner von Marco.

Self-contained Systems sind stark, wenn Organisation und Domäne dazu passen.

Sie sind schmerzhaft, wenn man sie nur baut, weil „autonome Teams“ in einer Folie gut aussah.

Multi-Tenant ist nicht nur tenantId

Ein weiterer Klassiker:

„Multi-Tenant? Machen wir einfach mit tenantId.“

Das ist einer dieser Sätze, bei denen Architektur kurz aus dem Fenster schaut und überlegt, ob sie heute noch gebraucht wird.

Natürlich kann ein tenantId Teil der Lösung sein.

Aber Mandantenfähigkeit ist selten nur ein Feld.

Es geht um Fragen wie:

• Müssen Daten strikt isoliert werden?
• Gibt es unterschiedliche Rollen- und Berechtigungsmodelle je Mandant?
• Gibt es mandantenspezifische Konfiguration?
• Unterschiedliche Workflows?
• Unterschiedliche Designs?
• Unterschiedliche Datenaufbewahrung?
• Unterschiedliche Integrationen?
• Unterschiedliche Release-Freigaben?
• Unterschiedliche regulatorische Anforderungen?
• Gemeinsame oder getrennte Datenbanken?
• Wie funktionieren Migrationen?
• Wie testet man mandantenspezifisches Verhalten?

Ein Login mit Rollen ist noch keine Multi-Tenant-Architektur.

Eine Anwendung, in der verschiedene Kundengruppen zufällig denselben Code benutzen, ist auch noch keine tragfähige Mandantenplattform.

Multi-Tenant wird dann zum Architekturtreiber, wenn Datenisolation, Konfiguration, Berechtigungen, Varianten und Betrieb nicht mehr nebenbei passieren können.

Und dann muss man es ernst nehmen.

Nicht panisch.

Aber ernst.

Cross-Platform heißt nicht „responsive UI“

Ähnlich ist es bei Cross-Platform.

Eine Web-App, die auf dem Handy nicht komplett zerbricht, ist nicht automatisch eine Cross-Platform-Strategie.

Mehrere Clients verändern ein System.

Ein Desktop-Web-Client hat andere Interaktionen als eine mobile App.
Eine öffentliche Consumer-App hat andere Sicherheitsanforderungen als ein internes Admin-Tool.
Ein Kiosk-Modus, eine native App, ein Portal und ein Backoffice sind nicht einfach vier Bildschirmgrößen.

Mehrere UIs beeinflussen:

• API-Design,
• ViewModels,
• Berechtigungen,
• Fehlerbehandlung,
• Offline-Fähigkeit,
• Caching,
• Navigation,
• Testing,
• Release-Zyklen,
• Design-System,
• Support,
• Monitoring,
• Produktverantwortung.

Cross-Platform wird dann zum Architekturtreiber, wenn unterschiedliche Clients nicht nur anders aussehen, sondern andere fachliche Nutzungsmodelle haben.

Multi-UI-Frameworks sind ebenfalls kein Selbstzweck.

Angular, React, Native, Web Components oder irgendein Shell-Konzept beantworten nicht automatisch die Frage, wie Fachlichkeit konsistent bleibt, welche UI gemeinsam ist, wo Varianten erlaubt sind und wie Teams Änderungen sicher ausrollen.

Technologie kann helfen.

Aber Technologie ersetzt keine Entscheidung.

„Wir bauen direkt skalierbar“ heißt oft: „Wir bauen direkt kompliziert“

Skalierbarkeit ist wichtig.

Aber viele Systeme sterben nicht daran, dass sie zu wenig horizontal skalieren.

Sie sterben daran, dass niemand mehr versteht, wo eine fachliche Änderung hingehört.

Oder dass das Team drei Tage braucht, um lokal alles zu starten.

Oder dass jede kleine Anpassung durch fünf Repositories, zwei Pipelines, drei Reviews und eine Abstimmungsrunde muss.

Oder dass der Betrieb zwar theoretisch professionell aussieht, praktisch aber niemand weiß, warum der Login im Preview nur manchmal geht.

„Skalierbar“ ist kein Freifahrtschein für maximale Architektur.

Skalierbar für was?

Für Nutzerlast?
Für Teams?
Für Features?
Für Mandanten?
Für Releases?
Für Integrationen?
Für regulatorische Anforderungen?
Für zehn Jahre Wartung?

Das sind unterschiedliche Skalierungen.

Und sie brauchen unterschiedliche Antworten.

Eine Architektur, die für Teamautonomie skaliert, kann für kleine Teams unnötig schwer sein.
Eine Architektur, die für Nutzerlast skaliert, kann fachlich trotzdem ein Schlammloch sein.
Eine Architektur, die für mehrere Produktlinien skaliert, kann für eine interne Fachanwendung absurd teuer sein.

Skalierbarkeit ohne konkreten Kontext ist nur ein schöneres Wort für Bauchgefühl.

Architektur ist keine rein technische Entscheidung

Ein weiterer Mythos:

„Architektur ist eine technische Entscheidung.“

Nein.

Architektur ist immer auch eine Team-, Produkt-, Betriebs- und Managemententscheidung.

Natürlich spielen technische Faktoren eine Rolle.

Frameworks, Laufzeiten, APIs, Datenbanken, Build-Systeme, Deployment, Security, Observability — alles wichtig.

Aber Architektur entscheidet auch:

• welche Teams voneinander abhängig sind,
• wer Änderungen freigeben muss,
• welche Teile gemeinsam verantwortet werden,
• wo Produktvarianten entstehen dürfen,
• wie schnell neue Features geliefert werden können,
• welche Fehler isoliert bleiben,
• wie teuer Betrieb wird,
• und wie lange neue Entwickler brauchen, um sinnvoll beitragen zu können.

Wenn Management eine Architektur will, die unabhängige Teams ermöglicht, muss es diese Teams auch wirklich geben.

Wenn ein Unternehmen Microservices will, aber nur ein Team hat, das nebenbei den Betrieb macht, dann ist das keine moderne Architektur.

Das ist ein Hobby mit Pager.

Wenn ein Produkt Multi-Tenant verkaufen will, muss es Mandantenfähigkeit als Produktfähigkeit begreifen — nicht als nachträgliche Datenbankspalte.

Architektur kann organisatorische Probleme nicht wegzaubern.

Sie kann sie sichtbar machen.

Manchmal ist das schon unangenehm genug.

Eine Entscheidungslandkarte

Statt Architektur nach Buzzword zu wählen, hilft eine nüchterne Landkarte.

Nicht perfekt. Nicht endgültig. Aber besser als „das machen gerade alle“.

1. Fachliche Komplexität

Wie viel echte Fachlichkeit steckt im System?

Geht es um einfache Datenpflege?
Oder um Regeln, Varianten, Workflows, Rollen, Statusübergänge, Berechnungen, Prüfungen und Ausnahmen?

Je höher die fachliche Komplexität, desto wichtiger werden klare Modelle, Grenzen, Use Cases und Tests.

Aber fachliche Komplexität allein bedeutet noch nicht Microservices.

Oft bedeutet sie zuerst: bessere Modularisierung.

2. Änderungsfrequenz

Welche Teile ändern sich häufig?

Ändern sich UI-Flows ständig?
Ändern sich fachliche Regeln?
Ändern sich Integrationen?
Ändern sich Mandantenanforderungen?
Ändern sich Produktlinien unabhängig voneinander?

Architektur sollte die absehbaren Änderungsrichtungen tragen.

Nicht die Fantasien eines zukünftigen Plattform-Imperiums.

3. Teamgröße und Teamautonomie

Wie viele Teams arbeiten wirklich am System?

Ein kleines Team braucht selten die gleiche Architektur wie fünf unabhängige Produktteams.

Wenn Teams unabhängig liefern sollen, müssen Grenzen, Verantwortlichkeiten und Deployments dazu passen.

Aber wenn alle Änderungen ohnehin durch dieselben drei Personen gehen, erzeugt maximale Verteilung oft nur maximale Koordination.

4. Anzahl der UIs und Clients

Gibt es eine UI?

Oder mehrere?

Admin, Consumer, Backoffice, Mobile, Kiosk, Partnerportal, interne Tools?

Mehrere Clients sind ein starker Architekturtreiber, wenn sie unterschiedliche Nutzungskontexte, Berechtigungen, Datenbedarfe und Release-Zyklen haben.

Dann werden BFFs, API-Schnitte, Design-Systeme und gemeinsame Modellgrenzen interessant.

Nicht, weil sie schön klingen.

Sondern weil sie echte Reibung reduzieren können.

5. Mandantenfähigkeit

Gibt es wirklich Mandanten?

Oder nur Benutzer mit Rollen?

Müssen Daten isoliert sein?
Müssen Workflows variieren?
Müssen Konfigurationen pro Kunde möglich sein?
Müssen Releases oder Features pro Mandant gesteuert werden?

Je stärker Mandantenfähigkeit das Produkt prägt, desto früher muss sie architektonisch modelliert werden.

Später „einfach tenantId ergänzen“ ist ungefähr so entspannt wie während der Fahrt die Achse wechseln.

6. Integrationsdruck

Wie viele externe Systeme hängen daran?

Sind diese Systeme stabil?
Oder ändern sie sich häufig?
Sind Datenmodelle fremd?
Gibt es Legacy-Systeme?
Gibt es asynchrone Prozesse?
Gibt es fachliche Übersetzung an Systemgrenzen?

Hoher Integrationsdruck spricht für klare Adapter, Anti-Corruption-Layer, robuste Schnittstellen und gute Observability.

Nicht automatisch für maximale Verteilung.

Aber definitiv gegen „wir reichen die DTOs einfach bis ins Template durch“.

7. Deployment-Unabhängigkeit

Müssen Teile unabhängig deploybar sein?

Wirklich?

Nicht „wäre irgendwie cool“.

Sondern: Gibt es fachliche, organisatorische oder regulatorische Gründe, warum Bereich A live gehen muss, während Bereich B unverändert bleibt?

Wenn ja, werden Microfrontends, Self-contained Systems oder Microservices interessanter.

Wenn nein, ist ein gemeinsames Deployment oft einfacher, sicherer und günstiger.

8. Betriebs- und Observability-Anforderungen

Kann das Team die Architektur betreiben?

Logging, Tracing, Metriken, Alerts, Fehleranalyse, Rollbacks, Datenmigrationen, lokale Entwicklung, Preview-Umgebungen, Security-Patches.

Verteilte Systeme ohne Observability sind keine moderne Architektur.

Sie sind ein Nebelwerfer.

Je verteilter ein System ist, desto mehr muss Betrieb von Anfang an mitgedacht werden.

Nicht später, wenn der erste Fehler nur noch als „504“ im Browser erscheint.

9. Lebensdauer der Anwendung

Ist das ein kurzlebiges Tool?

Ein MVP?

Ein internes Formular?

Eine Plattform, die zehn Jahre leben soll?

Langfristige Systeme brauchen andere Investitionen in Struktur, Tests, Modularität, Dokumentation und Ownership.

Aber auch hier gilt: Langfristigkeit rechtfertigt nicht jede Komplexität sofort.

Man kann Architektur entwickelbar bauen, ohne am ersten Tag das Endstadium zu simulieren.

10. Regulatorik, Berechtigungen und Datenisolation

Gibt es hohe Anforderungen an Datenschutz, Auditierbarkeit, Berechtigungen oder Datenisolation?

Dann ist Architektur nicht nur eine Frage von Codequalität.

Dann geht es um Vertrauen, Nachvollziehbarkeit, Zugriffskontrolle und Fehlerbegrenzung.

Das beeinflusst Datenmodelle, APIs, Logging, Tests, Rollenmodelle, Mandantenschnitte und Deployment-Strategien.

Und ja: Das ist unbequemer als „wir machen später noch Security“.

11. Risiko durch Overengineering

Die letzte Frage ist die unangenehmste:

Welche Architekturkomplexität können wir heute wirklich tragen?

Nicht theoretisch.

Heute.

Mit diesem Team.
Mit diesen Skills.
Mit diesem Budget.
Mit dieser Betriebsreife.
Mit dieser Produktunsicherheit.
Mit diesem Zeitdruck.

Overengineering fühlt sich am Anfang professionell an.

Später fühlt es sich an wie eine Mautstelle vor jeder Änderung.

Eine grobe Orientierung

Diese Tabelle ist keine Regel.

Sie ist eine Landkarte.

Und wie jede Landkarte ersetzt sie nicht den Blick aus dem Fenster.

Kontext	Häufig passende Richtung
Kleine App, kleines Team, überschaubare Fachlichkeit	einfacher, sauber strukturierter Monolith
Wachsende Fachlichkeit, ein oder wenige Teams, gemeinsames Deployment akzeptabel	modularer Monolith / Modulith
Mehrere Fachbereiche, klare Team-Ownership, unabhängige UI-Releases nötig	Microfrontends prüfen
Fachbereiche sollen Ende-zu-Ende inklusive UI, API, Daten und Betrieb autonom sein	Self-contained Systems prüfen
Services müssen unabhängig skalieren, deployen oder fachlich getrennt Daten besitzen	Microservices prüfen
Mehrere Mandanten mit Isolation, Konfiguration, Varianten und Berechtigungen	Multi-Tenant-Architektur bewusst entwerfen
Mehrere Clients mit unterschiedlichen Nutzungskontexten	Cross-Platform-Strategie, BFFs, Design-System prüfen
Viele Teams, gemeinsame UI-Sprache, wiederkehrende Patterns	Design System / UI-Plattform sinnvoll
Hoher Integrationsdruck zu Fremdsystemen	Adapter, ACLs, stabile API-Grenzen, Observability

Wichtig ist das Wort „prüfen“.

Nicht „nehmen“.

Architekturentscheidungen sind keine Paketbestellung.

Bessere Alternative: Architektur nach Belastung wählen

Eine bessere Architekturentscheidung beginnt nicht mit:

„Wollen wir Microfrontends?“

Sondern mit Fragen wie:

• Was muss unabhängig änderbar sein?
• Was muss unabhängig deploybar sein?
• Was muss fachlich getrennt bleiben?
• Was muss gemeinsam bleiben?
• Welche Daten gehören wirklich zusammen?
• Welche Teile ändern sich am häufigsten?
• Welche Teams besitzen welchen Bereich?
• Welche UI-Teile müssen konsistent bleiben?
• Welche Varianten sind Produktfähigkeit und welche nur Sonderfälle?
• Welche Komplexität können wir heute betreiben?
• Welche Komplexität brauchen wir wirklich?
• Was passiert, wenn wir falsch liegen?
• Können wir später sinnvoll wachsen, ohne heute alles vorzubauen?

Diese Fragen sind weniger glamourös als Architekturdiagramme mit vielen Kästchen.

Aber sie verhindern, dass man eine Architektur baut, die mehr über die Wünsche des Teams erzählt als über die Bedürfnisse des Produkts.

Was in späteren Artikeln genauer betrachtet wird

Dieser Artikel ist bewusst eine Übersicht.

Die einzelnen Architekturformen verdienen eigene Betrachtung, weil jede davon eigene Stärken, Fallen und Entscheidungsfragen hat.

Geplante Detailartikel:

• Monolith
  Wann ein gemeinsames System eine Stärke ist — und wann es kippt.

• Modulith
  Wie klare fachliche Grenzen ohne verteilten Betrieb funktionieren können.

• Microfrontend
  Wann unabhängige Frontends sinnvoll sind — und wann sie nur verteiltes Chaos erzeugen.

• Self-contained System
  Wie Ende-zu-Ende-Verantwortung aussieht und welche Reife sie voraussetzt.

• Microservices
  Warum Service-Schnitte mehr mit Daten, Ownership und Betrieb zu tun haben als mit Repository-Anzahl.

• Multi-Tenant-Architektur
  Warum Mandantenfähigkeit Produktfähigkeit ist — nicht nur ein Datenbankfeld.

• Cross-Platform Frontends
  Was mehrere Clients wirklich für APIs, ViewModels, Design-System und Releases bedeuten.

• BFF / API-Gateway
  Wann clientnahe APIs helfen und wann sie nur eine weitere Durchreiche werden.

• Design System / UI-Plattform
  Wann gemeinsame UI-Struktur Teams beschleunigt — und wann sie zum zentralen Flaschenhals wird.

Schluss

Gute Architektur ist nicht maximal groß.

Sie ist groß genug für das Problem — und klein genug, um noch verstanden zu werden.

Sie trägt die absehbaren Änderungsrichtungen.
Sie passt zur Teamstruktur.
Sie respektiert die Betriebsrealität.
Sie trennt, was getrennt werden muss.
Sie hält zusammen, was zusammengehört.

Und sie hat den Mut, nicht beeindruckender zu sein als nötig.

Gute Architektur ist nicht maximal groß. Gute Architektur ist groß genug für das Problem — und klein genug, um noch verstanden zu werden.