Add AI workspace reviews

decisions/0007-module-system.md

@@ -0,0 +1,102 @@
+# 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