# 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