4.3 KiB
4.3 KiB
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
- Autonomie: Jeder Context kann unabhängig entwickelt und deployed werden
- Skalierbarkeit: Contexts können individuell skaliert werden
- Technologie-Diversität: Verschiedene Technologien pro Context möglich
- Team-Autonomie: Teams können unabhängig an verschiedenen Contexts arbeiten
- Fehler-Isolation: Probleme in einem Context beeinträchtigen andere nicht