Decision Record · ADR-001

Modularer Monolith als Ausgangspunkt, Microservices auf Nachweis

Neue Systeme beginnen als modularer Monolith mit expliziten Modulgrenzen. Einzelne Dienste werden nur herausgelöst, wenn eine konkrete Anforderung es rechtfertigt.

Was ist das? · Decision Record

Eine dokumentierte Architekturentscheidung im ADR-Format — Kontext, geprüfte Optionen, Begründung und Konsequenzen. Eine konkrete Entscheidung, kein allgemeiner Leitfaden. Zur Übersicht

Status
Angenommen
Kennung
ADR-001
Überprüfung
Zu prüfen, sobald ein Modul nachweislich unabhängige Skalierung oder unabhängiges Deployment verlangt.

Kontext

Neue Systeme müssen sich zwischen einem einzelnen Deployment (Monolith) und verteilten Diensten (Microservices) entscheiden. Die Wahl prägt Betrieb, Änderbarkeit und Kosten über Jahre.

Problem

Verteilte Systeme lösen reale Probleme — unabhängige Skalierung, unabhängiges Deployment — bringen aber Netzwerkgrenzen, eventual consistency und Betriebsaufwand mit. Wann rechtfertigt der Nutzen diese Kosten?

Optionen

Was wir geprüft haben.

  1. A

    Modularer Monolith

    Ein Deployment, klare Modulgrenzen in einer Codebasis.

  2. B

    Microservices von Beginn an

    Mehrere Dienste, unabhängig deploybar und skalierbar.

  3. C

    Verteilter Monolith

    Mehrere Dienste ohne echte Entkopplung — die schlechteste Variante.

Entscheidung

Was wir entschieden haben.

Neue Systeme beginnen als modularer Monolith mit expliziten Modulgrenzen. Einzelne Dienste werden nur herausgelöst, wenn eine konkrete Anforderung es rechtfertigt.

Warum diese Entscheidung

Der modulare Monolith hält die teuren Entscheidungen offen. Grenzen sind explizit, aber ihre Überschreitung kostet keinen Netzwerk-Hop; der Betrieb bleibt einfach. Saubere Module lassen sich später gezielt verteilen — die umgekehrte Richtung ist deutlich teurer.

Konsequenzen

  • Der Dienst skaliert als Ganzes; einzelne Teile lassen sich nicht unabhängig skalieren.
  • Moduldisziplin muss aktiv gewahrt werden, sonst droht ein großer Ball aus Schlamm.
  • Ein späteres Herauslösen eines Moduls ist eine bewusste, eigene Entscheidung.

Verworfene Alternativen

  • Microservices als DefaultZahlt die Kosten verteilter Systeme, bevor der Nutzen feststeht.
  • Serverless-firstBindet früh an Betriebsmodell und Anbieter, bevor Lastprofile bekannt sind.
Wissensgraph

Setzen Sie Ihren Engineering-Weg fort.

Verwandte Konzepte, Entscheidungen, Playbooks und Standpunkte — als zusammenhängender Pfad, nicht als Linkliste.

Vor einer ähnlichen Entscheidung?

Wir treffen sie nicht aus dem Bauch. Sprechen Sie mit der Geschäftsführung — technisch, ohne Vertrieb.