StefanMoCoAt
14770003bd
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
92 lines
4.8 KiB
Markdown
92 lines
4.8 KiB
Markdown
# ADR-0003: Microservices-Architektur
|
|
|
|
## Status
|
|
|
|
Akzeptiert
|
|
|
|
## Kontext
|
|
|
|
Nach der Entscheidung, eine modulare Architektur ([ADR-0001](0001-modular-architecture-de.md)) und Domain-Driven
|
|
Design ([ADR-0002](0002-domain-driven-design-de.md)) zu übernehmen, mussten wir die Deployment-Strategie für unsere
|
|
Module festlegen. Zu den wichtigsten Überlegungen gehörten:
|
|
|
|
1. Unabhängige Skalierbarkeit verschiedener Teile des Systems
|
|
2. Deployment-Unabhängigkeit, um Teams zu ermöglichen, Änderungen ohne Koordination mit anderen Teams zu veröffentlichen
|
|
3. Technologieunabhängigkeit, um verschiedenen Diensten die Verwendung unterschiedlicher Technologien nach Bedarf zu
|
|
ermöglichen
|
|
4. Resilienz, um sicherzustellen, dass Ausfälle in einem Teil des Systems nicht das gesamte System beeinträchtigen
|
|
5. Klare Zuständigkeitsgrenzen, die mit den Team-Verantwortlichkeiten übereinstimmen
|
|
|
|
## Entscheidung
|
|
|
|
Wir haben uns entschieden, eine Microservices-Architektur zu implementieren, bei der jedes Domänenmodul als separater
|
|
Dienst bereitgestellt wird:
|
|
|
|
- **masterdata-service**: Verwaltet Stammdaten wie Standorte, Disziplinen usw.
|
|
- **members-service**: Verwaltet Mitgliederregistrierung und -profile
|
|
- **horses-service**: Verwaltet Pferderegistrierung und -informationen
|
|
- **events-service**: Verwaltet Veranstaltungserstellung, -planung und -anmeldungen
|
|
|
|
Jeder Dienst:
|
|
|
|
- Hat sein eigenes Datenbankschema
|
|
- Ist unabhängig bereitstellbar
|
|
- Kommuniziert mit anderen Diensten über klar definierte APIs und nachrichtenbasierte Kommunikation
|
|
- Ist für seine eigene Domänenlogik gemäß DDD-Prinzipien verantwortlich
|
|
|
|
Wir haben auch unterstützende Infrastrukturdienste implementiert:
|
|
|
|
- **gateway**: API-Gateway für Routing und Authentifizierung
|
|
- **auth**: Authentifizierung- und Autorisierungsdienst (Keycloak)
|
|
- **cache**: Caching-Dienst (Redis)
|
|
- **messaging**: Message Broker für die Kommunikation zwischen Diensten (Kafka)
|
|
- **monitoring**: Überwachung- und Beobachtbarkeitsdienste
|
|
|
|
## Konsequenzen
|
|
|
|
### Positive
|
|
|
|
- **Unabhängige Skalierbarkeit**: Jeder Dienst kann basierend auf seinen spezifischen Lastanforderungen skaliert werden
|
|
- **Deployment-Unabhängigkeit**: Teams können Änderungen an ihren Diensten bereitstellen, ohne sich mit anderen Teams
|
|
abstimmen zu müssen
|
|
- **Technologieflexibilität**: Verschiedene Dienste können je nach Bedarf unterschiedliche Technologien verwenden
|
|
- **Resilienz**: Ausfälle in einem Dienst beeinträchtigen nicht unbedingt andere
|
|
- **Klare Zuständigkeit**: Jeder Dienst hat klare Zuständigkeitsgrenzen, die mit den Team-Verantwortlichkeiten
|
|
übereinstimmen
|
|
- **Kleinere Codebasen**: Jeder Dienst hat eine kleinere, fokussierte Codebasis
|
|
|
|
### Negative
|
|
|
|
- **Komplexität verteilter Systeme**: Microservices bringen die Herausforderungen verteilter Systeme mit sich
|
|
- **Betrieblicher Mehraufwand**: Mehr Dienste müssen bereitgestellt, überwacht und gewartet werden
|
|
- **Herausforderungen bei der Datenkonsistenz**: Die Aufrechterhaltung der Datenkonsistenz über Dienste hinweg erfordert
|
|
sorgfältiges Design
|
|
- **Netzwerklatenz**: Die Kommunikation zwischen Diensten fügt Latenz hinzu
|
|
- **Testkomplexität**: End-to-End-Tests werden komplexer
|
|
|
|
### Neutral
|
|
|
|
- **Teamorganisation**: Teams müssen um Dienste statt um Features herum organisiert werden
|
|
- **Dokumentationsbedarf**: Dienstschnittstellen und -interaktionen müssen gut dokumentiert sein
|
|
|
|
## Betrachtete Alternativen
|
|
|
|
### Modularer Monolith
|
|
|
|
Wir haben die Implementierung eines modularen Monolithen in Betracht gezogen, bei dem alle Module als eine einzige
|
|
Anwendung bereitgestellt werden, jedoch mit klaren Modulgrenzen. Dies wäre einfacher bereitzustellen gewesen und hätte
|
|
die Herausforderungen verteilter Systeme vermieden, hätte aber nicht die Vorteile der unabhängigen Skalierbarkeit und
|
|
Bereitstellung geboten.
|
|
|
|
### Service-basierte Architektur
|
|
|
|
Wir haben eine Dienst-basierte Architektur mit weniger bzw. größeren Diensten in Betracht gezogen, die mehrere
|
|
Domänenbereiche umfassen würden. Dies hätte den betrieblichen Overhead reduziert, aber es schwieriger gemacht, klare
|
|
Domänengrenzen und unabhängige Skalierbarkeit aufrechtzuerhalten.
|
|
|
|
## Referenzen
|
|
|
|
- [Microservices von Martin Fowler](https://meldestelle-pro.youtrack.cloud/api/files/526-16?sign=MTc2MjU2MDAwMDAwMHwyLTF8NTI2LTE2fFViVXRuTGdXcFhIcFRwdG03ZHlSZEZ5ZEc2MG5VVVB3SGJ4OUFRRG82QlENCg&updated=1762340608616)
|
|
- [Building Microservices von Sam Newman](https://meldestelle-pro.youtrack.cloud/api/files/526-17?sign=MTc2MjU2MDAwMDAwMHwyLTF8NTI2LTE3fDdjaXJoZ0NlWlQ1MW9tZ0UwdC1fLVZEZ0pUcFF6QnNScTcxN0Z6YlVUazQNCg&updated=1762340788707)
|
|
- [Microservices Patterns von Chris Richardson](https://meldestelle-pro.youtrack.cloud/api/files/526-20?sign=MTc2MjU2MDAwMDAwMHwyLTF8NTI2LTIwfDM5S08yMXVENmFRa1NPaEROQlR1N1Nvc0lWWUJXU0hCR1JYTVJXSDA2RGcNCg&updated=1762340989301)
|