StefanMoCoAt 14770003bd chore(MP-30): final docs cleanup, adr consolidation & legacy removal

Summary
- **Documentation Cleanup:**
  - ADRs consolidated to `docs/adr/`.
  - C4 diagrams moved to `docs/c4/`.
  - Removed legacy folder `docs/architecture/` and `docs/clients/`.
- **New ADR:** Added `0009-final-kmp-architecture.md` (Accepted).
- **Updates:**
  - `ARCHITECTURE.md` updated with final folder structure (Core Modules).
  - `README.md` links fixed.
- **Verification:**
  - `./gradlew staticAnalysis` -> SUCCESS.
  - Path references checked.

Ref: MP-30

2025-12-08 18:04:44 +01:00

3.5 KiB

Raw Blame History

ADR-0001: Modulare Architektur

Status

Akzeptiert

Kontext

Das Meldestelle-System wurde ursprünglich als monolithische Anwendung entwickelt. Mit zunehmender Komplexität und Größe des Systems traten mehrere Herausforderungen auf:

Der Quellcode wurde schwer zu warten und zu verstehen
Entwicklungsteams mussten sich eng koordinieren, was die Entwicklung verlangsamte
Die gesamte Anwendung musste skaliert werden, auch wenn nur bestimmte Teile mehr Ressourcen benötigten
Technologieentscheidungen wurden durch die monolithische Architektur eingeschränkt

Das Team musste entscheiden, ob es mit dem monolithischen Ansatz fortfahren oder zu einer modularenen Architektur migrieren sollte.

Entscheidung

Wir haben uns entschieden, von einer monolithischen Struktur zu einer modularen Architektur zu migrieren und das System in die folgenden Module zu organisieren:

core: Gemeinsame Kernkomponenten
masterdata: Stammdatenverwaltung
members: Mitgliederverwaltung
horses: Pferderegistrierung
events: Veranstaltungsverwaltung
infrastructure: Gemeinsame Infrastrukturkomponenten
client: Client-Anwendungen

Jedes Domänenmodul (masterdata, members, horses, events) folgt einem Clean-Architecture-Ansatz mit separaten API-, Anwendung-, Domänen-, Infrastruktur- und Service-Schichten.

Konsequenzen

Positive

Verbesserte Wartbarkeit: Kleinere, fokussierte Module sind leichter zu verstehen und zu warten
Unabhängige Entwicklung: Teams können an verschiedenen Modulen mit minimaler Koordination arbeiten
Selektive Skalierung: Einzelne Module können basierend auf ihren spezifischen Anforderungen skaliert werden
Technologieflexibilität: Verschiedene Module können je nach Bedarf unterschiedliche Technologien verwenden
Klare Grenzen: Domänengrenzen sind explizit definiert, was die konzeptionelle Integrität des Systems verbessert

Negative

Erhöhte Komplexität: Die Gesamtsystemarchitektur ist komplexer
Deployment-Overhead: Mehr Komponenten müssen bereitgestellt und verwaltet werden
Leistungsüberlegungen: Modulübergreifende Kommunikation fügt Latenz hinzu
Migrationsaufwand: Erheblicher Aufwand erforderlich, um von der monolithischen Struktur zu migrieren

Neutral

Teamorganisation: Teams müssen um Module statt um Features herum organisiert werden
Dokumentationsbedarf: Umfassendere Dokumentation ist erforderlich, um das System als Ganzes zu verstehen

Betrachtete Alternativen

Erweiterter Monolith

Wir haben in Betracht gezogen, die interne Struktur des Monolithen mit besseren Modulgrenzen zu verbessern, ihn aber als eine einzige bereitstellbare Einheit zu behalten. Dies wäre einfacher bereitzustellen gewesen, hätte aber die Probleme mit der Skalierung und Technologieflexibilität nicht gelöst.

Microservices

Wir haben einen feingranularen Microservices-Ansatz mit vielen kleineren Diensten in Betracht gezogen. Dies hätte maximale Flexibilität geboten, aber für unsere aktuellen Bedürfnisse übermäßige Komplexität und betrieblichen Overhead eingeführt.

3.5 KiB Raw Blame History