# ADR-0001: Modularer Monolith statt Microservices

* Status: Angenommen
* Datum: 2026-08-17 (nachträglich dokumentiert; Entscheidung war bereits mit dem ersten Commit
  wirksam)

## Kontext und Problemstellung

PROCUREX bildet einen Procure-to-Pay-Prozess mit acht fachlichen Bounded Contexts ab (Supplier,
Catalog, Requisition, Ordering, Approval, Receiving, Invoicing, Notification). Für ein
Lernprojekt ohne eigenes Kubernetes-Cluster und ohne mehrköpfiges Team stellt sich die Frage, ob
diese Contexts als eigenständige deploybare Services oder als Module innerhalb eines Artefakts
umgesetzt werden.

## Entscheidungstreiber

* Kein produktiver Kubernetes-Cluster in der Lernumgebung verfügbar (siehe Confluence Seite 12).
* Ein einzelner Entwickler/Lernender, kein Team mit Bedarf an unabhängiger Deploybarkeit.
* Trotzdem soll die Struktur eine spätere Auftrennung in Services nicht verbauen.

## Betrachtete Optionen

* Microservices: ein Deployment-Artefakt pro Bounded Context.
* Modularer Monolith: ein deploybares Spring-Boot-Artefakt (`procurex-app`), Bounded Contexts als
  eigene Maven-Module mit Hexagonal-Struktur und eigenem PostgreSQL-Schema.
* Klassischer Layered Monolith ohne Modulgrenzen.

## Entscheidung

Modularer Monolith. Jedes Modul besitzt sein eigenes PostgreSQL-Schema und wird intern nach
Ports & Adapters gegliedert (`domain`, `application`, `adapter.in`, `adapter.out`). Modul-zu-Modul-
Kommunikation läuft synchron nur über öffentliche Application-Service-Interfaces und asynchron
über Kafka-Events mit Transactional Outbox (siehe ADR-0003). Kein Modul greift direkt auf das
Schema eines anderen Moduls zu.

## Begründung

* Ein Betriebsartefakt reduziert die Betriebslast (ein Prozess, ein Deployment, eine JVM) in einer
  Umgebung ohne Cluster-Orchestrierung.
* Schema-pro-Modul und Kafka-Outbox zwischen den Modulen halten die Kopplung so lose, dass eine
  spätere Auftrennung in eigenständige Services technisch möglich bliebe, ohne dass diese Option
  aktuell gebraucht wird.
* Microservices hätten den Betriebsaufwand (Service Discovery, verteiltes Tracing, mehrere
  CI/CD-Pipelines) ohne einen entsprechenden Nutzen für dieses Lernprojekt erhöht.

## Konsequenzen

* Positiv: einfacherer lokaler Start (`mvn -pl procurex-app -am spring-boot:run`), ein
  Docker-Image für das Backend, ein Helm-Deployment.
* Negativ: alle Module teilen sich Prozess- und Speicherressourcen; ein Modul kann den gesamten
  Prozess durch Ressourcenerschöpfung beeinträchtigen (kein Bulkhead über Prozessgrenzen).
* Negativ: unabhängige Skalierung einzelner Bounded Contexts ist ohne weitere Auftrennung nicht
  möglich.

## Weitere Informationen

Siehe Confluence Seite 09 „Zielarchitektur und Modulstruktur“ (CONFIRMED) sowie `pom.xml`
(Modulliste) und `README.md` im Repo-Root.