Hosting-Backoffice/decisions/0007-module-system.md

ADR 0007 — Modul-System

Status

Accepted

Kurz erklärt

Das Modul-System legt fest, wie Funktionen voneinander getrennt werden.

Ziel ist:

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:

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