Files
2026-05-18 04:37:23 +00:00

103 lines
1.8 KiB
Markdown

# ADR 0007 — Modul-System
## Status
Accepted
## Kurz erklärt
Das Modul-System legt fest, wie Funktionen voneinander getrennt werden.
Ziel ist:
```text
modular denken,
aber V1 nicht technisch überkomplizieren.
```
## Kontext
Das Projekt soll kein klassischer Monolith werden.
Gleichzeitig wäre ein echtes Microservice-System für V1 zu komplex.
## Entscheidung
V1 verwendet ein modulares In-App-Modell innerhalb einer Laravel-Anwendung.
Module sind logisch getrennt, laufen aber im selben Deployment.
## Warum kein Microservice-System?
Microservices bedeuten:
- mehrere Deployments
- mehrere Services
- Service-Kommunikation
- verteiltes Logging
- verteilte Fehlerbilder
- mehr DevOps-Aufwand
Für V1 wäre das zu schwer.
## Modularten
### Core
Minimaler Plattformkern.
### Service-Module
Fachliche Module wie:
- Kunden
- Verträge
- Domains
- Hosting
- Tickets
- Dokumente
- Billing
### Integrationsmodule
Adapter zu externen Systemen wie:
- KeyHelp
- 1blu
- Lexware
- Invoice Ninja
## Technische Leitlinien
Module kommunizieren über:
- Service-Contracts
- Events
- definierte Interfaces
Nicht erlaubt:
```text
Modul A verändert ungeprüft interne Tabellen von Modul B.
```
## Modul-Lifecycle
Module sollen später Zustände haben:
- installiert
- aktiviert
- deaktiviert
- aktualisiert
- archiviert
Deinstallation mit Datenlöschung ist nicht Standard.
## Konsequenzen
### Positiv
- V1 bleibt betreibbar
- Architektur bleibt modular
- keine Microservice-Komplexität
- spätere Auslagerung einzelner Module bleibt möglich
### Negativ
- strikte Disziplin nötig
- Modulgrenzen müssen geprüft werden
- ohne klare Contracts droht trotzdem ein Monolith
## Verwandte ADRs
- ADR 0009 — Core-Grenzen
- ADR 0008 — External-Reference-Pattern
- ADR 0016 — Modul-Lifecycle