stefan
196 lines
4.3 KiB
Markdown
196 lines
4.3 KiB
Markdown
# Bounded Contexts Design für Self-Contained Systems
|
|
|
|
## Übersicht
|
|
|
|
Das Meldestelle-System wird in 7 Bounded Contexts unterteilt, um eine Self-Contained Systems (SCS) Architektur zu implementieren.
|
|
|
|
## Bounded Contexts
|
|
|
|
### 1. Member Management Context (member-management)
|
|
**Verantwortlichkeiten:**
|
|
- Personenverwaltung (Reiter, Funktionäre, Kontaktpersonen)
|
|
- Vereinsverwaltung (Reitvereine, Verbände)
|
|
- Mitgliedschaftsbeziehungen
|
|
|
|
**Kern-Entitäten:**
|
|
- DomPerson
|
|
- DomVerein
|
|
|
|
**APIs:**
|
|
- `/api/members/persons`
|
|
- `/api/members/clubs`
|
|
- `/api/members/memberships`
|
|
|
|
**Abhängigkeiten:**
|
|
- Master Data Context (für Länder/Bundesländer)
|
|
- Data Integration Context (für ZNS Import)
|
|
|
|
---
|
|
|
|
### 2. Horse Registry Context (horse-registry)
|
|
**Verantwortlichkeiten:**
|
|
- Pferderegistrierung und -verwaltung
|
|
- Besitzverhältnisse
|
|
- Abstammungsinformationen
|
|
|
|
**Kern-Entitäten:**
|
|
- DomPferd
|
|
|
|
**APIs:**
|
|
- `/api/horses`
|
|
- `/api/horses/ownership`
|
|
- `/api/horses/pedigree`
|
|
|
|
**Abhängigkeiten:**
|
|
- Member Management Context (für Besitzer/Verantwortliche)
|
|
- Data Integration Context (für ZNS Import)
|
|
|
|
---
|
|
|
|
### 3. License & Qualification Context (license-management)
|
|
**Verantwortlichkeiten:**
|
|
- Lizenzverwaltung
|
|
- Qualifikationstracking
|
|
- Gültigkeitsüberwachung
|
|
|
|
**Kern-Entitäten:**
|
|
- DomLizenz
|
|
- DomQualifikation
|
|
- LizenzTypGlobal
|
|
- QualifikationsTyp
|
|
|
|
**APIs:**
|
|
- `/api/licenses`
|
|
- `/api/qualifications`
|
|
- `/api/licenses/validity`
|
|
|
|
**Abhängigkeiten:**
|
|
- Member Management Context (für Lizenzinhaber)
|
|
- Master Data Context (für Lizenztypen)
|
|
|
|
---
|
|
|
|
### 4. Event Management Context (event-management)
|
|
**Verantwortlichkeiten:**
|
|
- Turnier- und Veranstaltungsorganisation
|
|
- Terminplanung
|
|
- Veranstaltungsrahmen
|
|
|
|
**Kern-Entitäten:**
|
|
- Turnier
|
|
- Veranstaltung
|
|
- VeranstaltungsRahmen
|
|
- Pruefung_Abteilung
|
|
|
|
**APIs:**
|
|
- `/api/events`
|
|
- `/api/tournaments`
|
|
- `/api/events/schedule`
|
|
|
|
**Abhängigkeiten:**
|
|
- Member Management Context (für Funktionäre)
|
|
- Master Data Context (für Plätze)
|
|
- Competition Management Context (für Bewerbe)
|
|
|
|
---
|
|
|
|
### 5. Master Data Context (master-data)
|
|
**Verantwortlichkeiten:**
|
|
- Referenzdatenverwaltung
|
|
- Geografische Daten
|
|
- Altersklassendefinitionen
|
|
|
|
**Kern-Entitäten:**
|
|
- BundeslandDefinition
|
|
- LandDefinition
|
|
- AltersklasseDefinition
|
|
- Sportfachliche_Stammdaten
|
|
- Platz
|
|
|
|
**APIs:**
|
|
- `/api/masterdata/countries`
|
|
- `/api/masterdata/states`
|
|
- `/api/masterdata/age-classes`
|
|
- `/api/masterdata/venues`
|
|
|
|
**Abhängigkeiten:**
|
|
- Keine (Basis-Context)
|
|
|
|
---
|
|
|
|
### 6. Data Integration Context (data-integration)
|
|
**Verantwortlichkeiten:**
|
|
- OEPS ZNS Datenimport
|
|
- Datentransformation
|
|
- Staging-Management
|
|
|
|
**Kern-Entitäten:**
|
|
- Person_ZNS_Staging
|
|
- Pferd_ZNS_Staging
|
|
- Verein_ZNS_Staging
|
|
|
|
**APIs:**
|
|
- `/api/integration/import`
|
|
- `/api/integration/staging`
|
|
- `/api/integration/validation`
|
|
|
|
**Abhängigkeiten:**
|
|
- Alle anderen Contexts (für Datenverteilung)
|
|
|
|
---
|
|
|
|
### 7. Competition Management Context (competition-management)
|
|
**Verantwortlichkeiten:**
|
|
- Bewerbssetup
|
|
- Disziplin-spezifische Regeln
|
|
- Wertungssystem
|
|
|
|
**Kern-Entitäten:**
|
|
- Bewerb
|
|
- Abteilung
|
|
- Pruefungsaufgabe
|
|
- DressurPruefungSpezifika
|
|
- SpringPruefungSpezifika
|
|
- Meisterschaft_Cup_Serie
|
|
|
|
**APIs:**
|
|
- `/api/competitions`
|
|
- `/api/competitions/disciplines`
|
|
- `/api/competitions/scoring`
|
|
|
|
**Abhängigkeiten:**
|
|
- Event Management Context (für Turniere)
|
|
- Member Management Context (für Teilnehmer)
|
|
- Horse Registry Context (für Pferde)
|
|
|
|
## Inter-Context Communication
|
|
|
|
### Synchrone Kommunikation
|
|
- REST APIs zwischen Contexts
|
|
- Shared DTOs für Datenaustausch
|
|
|
|
### Asynchrone Kommunikation
|
|
- Event-basierte Kommunikation für lose Kopplung
|
|
- Domain Events für wichtige Geschäftsereignisse
|
|
|
|
### Shared Kernel
|
|
- Gemeinsame Enums und Basis-DTOs
|
|
- Serializer und Validatoren
|
|
- Utility-Klassen
|
|
|
|
## Deployment-Strategie
|
|
|
|
Jeder Bounded Context wird als separates Modul implementiert:
|
|
- Eigene Gradle-Module
|
|
- Separate Datenbank-Schemas (optional)
|
|
- Unabhängige Deployment-Einheiten
|
|
- Eigene API-Endpunkte
|
|
|
|
## Vorteile der SCS-Architektur
|
|
|
|
1. **Autonomie**: Jeder Context kann unabhängig entwickelt und deployed werden
|
|
2. **Skalierbarkeit**: Contexts können individuell skaliert werden
|
|
3. **Technologie-Diversität**: Verschiedene Technologien pro Context möglich
|
|
4. **Team-Autonomie**: Teams können unabhängig an verschiedenen Contexts arbeiten
|
|
5. **Fehler-Isolation**: Probleme in einem Context beeinträchtigen andere nicht
|