# 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 ```text 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. ## Verwandte ADRs - ADR 0007 — Modul-System - ADR 0008 — External-Reference-Pattern - ADR 0016 — Modul-Lifecycle