Stefan Mogeritsch
09b0b1a462
Streamlined Keycloak configurations with defaults for development and production in `.env`. Added health checks and improved environment variable documentation with comments to differentiate local and server deployments. Ensured compatibility with pre-built registry images.
3.6 KiB
| type | status | owner |
|---|---|---|
| ADR | ACTIVE | Lead Architect |
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.