107 lines
2.2 KiB
Markdown
107 lines
2.2 KiB
Markdown
# 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
|