stefan
9282dd0eb4
1. **Dokumentation der Architektur:**
- Vervollständigen Sie die C4-Diagramme im docs-Verzeichnis
- Dokumentieren Sie die wichtigsten Architekturentscheidungen in ADRs
2. **Redis-Integration finalisieren:**
- Implementieren Sie die verteilte Cache-Lösung für die Offline-Fähigkeit
- Nutzen Sie Redis Streams für das Event-Sourcing
3.8 KiB
ADR-0003: Microservices Architecture
Status
Accepted
Context
Following the decision to adopt a modular architecture (ADR-0001) and Domain-Driven Design (ADR-0002), we needed to determine the deployment strategy for our modules. Key considerations included:
- Independent scalability of different parts of the system
- Deployment independence to allow teams to release changes without coordinating with other teams
- Technology independence to allow different services to use different technologies as appropriate
- Resilience to ensure that failures in one part of the system don't bring down the entire system
- Clear ownership boundaries aligned with team responsibilities
Decision
We decided to implement a microservices architecture where each domain module is deployed as a separate service:
- masterdata-service: Manages master data such as locations, disciplines, etc.
- members-service: Manages member registration and profiles
- horses-service: Manages horse registration and information
- events-service: Manages event creation, scheduling, and registrations
Each service:
- Has its own database schema
- Is independently deployable
- Communicates with other services through well-defined APIs and message-based communication
- Is responsible for its own domain logic as per DDD principles
We also implemented supporting infrastructure services:
- gateway: API Gateway for routing and authentication
- auth: Authentication and authorization service (Keycloak)
- cache: Caching service (Redis)
- messaging: Message broker for inter-service communication (Kafka)
- monitoring: Monitoring and observability services
Consequences
Positive
- Independent scalability: Each service can be scaled based on its specific load requirements
- Deployment independence: Teams can deploy changes to their services without coordinating with other teams
- Technology flexibility: Different services can use different technologies as appropriate
- Resilience: Failures in one service don't necessarily affect others
- Clear ownership: Each service has clear ownership boundaries aligned with team responsibilities
- Smaller codebases: Each service has a smaller, more focused codebase
Negative
- Distributed system complexity: Microservices introduce the challenges of distributed systems
- Operational overhead: More services to deploy, monitor, and maintain
- Data consistency challenges: Maintaining data consistency across services requires careful design
- Network latency: Inter-service communication adds latency
- Testing complexity: End-to-end testing becomes more complex
Neutral
- Team organization: Teams need to be organized around services rather than features
- Documentation needs: Service interfaces and interactions need to be well-documented
Alternatives Considered
Modular Monolith
We considered implementing a modular monolith where all modules would be deployed as a single application but with clear module boundaries. This would have been simpler to deploy and would have avoided the distributed system challenges, but would not have provided the independent scalability and deployment benefits.
Service-Based Architecture
We considered a service-based architecture with fewer, larger services that would encompass multiple domain areas. This would have reduced the operational overhead but would have made it harder to maintain clear domain boundaries and independent scalability.