31 lines
1.6 KiB
Markdown
Executable File
31 lines
1.6 KiB
Markdown
Executable File
# ADR-009: Konzernplattform als Modul-Monolith
|
||
|
||
**Datum:** 2026-07-15 · **Status:** Akzeptiert · **Vorgabe:** "Wir machen aus dem ITSM eine Konzernplattform inkl. HR, CRM, usw."
|
||
|
||
## Kontext
|
||
Das ITSM soll zur Unternehmensplattform mit Fachmodulen (HR, CRM, weitere)
|
||
werden. Es existiert bereits ein Erweiterungs-Muster (AES-Suite unter
|
||
/erweiterungen mit eigener Rolle aes_user). Alternativen: separate Services
|
||
je Domaene mit SSO vs. Module im bestehenden Binary.
|
||
|
||
## Entscheidung
|
||
Modul-Monolith: Fachmodule sind Rust-Module im ITSM-Binary und teilen sich
|
||
Mandantentrennung, Auth/Sessions, CSRF, Audit-Log, Retention, UI-Shell und
|
||
Deployment. Je Modul: eigenes src/<modul>.rs, eigene Tabellen mit Praefix
|
||
(hr_*, crm_*), eigene Rolle(n) fuer den Zugriff (hr_manager, crm_agent),
|
||
eigene Nav-Gruppe. Der Kern (web.rs/db.rs/security.rs) bleibt modulagnostisch.
|
||
|
||
HR-Daten sind besonders schuetzenswert: Zugriff ausschliesslich admin +
|
||
hr_manager — operative ITSM-Rollen (change_manager, agent) sehen HR NICHT.
|
||
CRM: admin + crm_agent.
|
||
|
||
## Konsequenzen
|
||
+ Ein Deployment, eine DB, konsistente Sicherheit/Audit ueber alle Module;
|
||
schnellste Iterationsgeschwindigkeit bei aktueller Teamgroesse (1).
|
||
+ Modul-Verknuepfungen (Kunde<->Ticket, Onboarding->Service Request) sind
|
||
einfache Joins statt Service-APIs.
|
||
− Ein-Rollen-Modell wird mit wachsender Modulzahl eng — Abloesung durch
|
||
Modul-Grants ist als Plattform-phase-004 eingeplant.
|
||
− Bei stark divergenter Last oder Team-Skalierung waere ein Service-Split
|
||
ein neuer ADR; die Praefix-Trennung der Tabellen haelt diesen Weg offen.
|