Add AI workspace reviews
This commit is contained in:
@@ -0,0 +1,106 @@
|
||||
# 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
|
||||
Reference in New Issue
Block a user