ADR 0009 — Core-Grenzen

Status

Accepted

Kurz erklärt

Core-Grenzen legen fest, was wirklich in den Plattformkern gehört.

Je größer der Core wird, desto höher ist das Risiko, dass das System trotz Modulidee zu einem Monolithen wird.

Kontext

Das Architekturreview hat kritisiert, dass der bisherige Core zu groß definiert war.

Bisher waren u. a. Kunden, Domains, Server, Produkte, Dokumente und Benachrichtigungen im Core vorgesehen.

Das widerspricht dem Ziel eines modularen Systems.

Entscheidung

Der Core wird bewusst klein gehalten.

Der Core enthält nur technische und organisatorische Plattformfunktionen, die alle Module benötigen.

Core enthält

Identity
Authentication
Tenant Context
RBAC / Policies
Audit-Grundstruktur
Module Registry
Settings-Grundstruktur
Event Routing
API-Basis
System Health

Core enthält NICHT

Kundenfachlogik
Domainfachlogik
Billingfachlogik
Hostingfachlogik
Ticketsystemfachlogik
Dokumentenarchivfachlogik
Anbieterlogik

Diese Bereiche werden als Service-Module oder Integrationsmodule behandelt.

Neue Struktur

Core
├── Identity
├── Tenancy
├── RBAC
├── Audit Base
├── Module Registry
├── Settings Base
├── Event Routing
└── API Base

Service Modules
├── Customers
├── Contracts
├── Products
├── Domains
├── Hosting
├── Billing
├── Tickets
├── Documents
└── Notifications

Integration Modules
├── KeyHelp
├── 1blu
├── Lexware
└── Invoice Ninja

Begründung

Ein kleiner Core reduziert:

Kopplung
Refactoring-Risiken
Monolith-Gefahr
Abhängigkeiten zwischen Fachbereichen

Konsequenzen

Positiv

sauberere Modulgrenzen
leichter testbar
langfristig besser erweiterbar
neue Integrationen einfacher möglich

Negativ

mehr Architekturdisziplin nötig
Module brauchen definierte Contracts
anfänglich mehr Planungsaufwand

Regel

Wenn ein Bereich fachliche Geschäftslogik enthält, gehört er nicht in den Core.

2.2 KiB Raw Blame History