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.1 KiB
ADR-0001: Modular Architecture
Status
Accepted
Context
The Meldestelle system was initially developed as a monolithic application. As the system grew in complexity and size, several challenges emerged:
- The codebase became difficult to maintain and understand
- Development teams had to coordinate closely, slowing down development
- Scaling the entire application was necessary even when only specific parts needed more resources
- Technology choices were constrained by the monolithic architecture
The team needed to decide whether to continue with the monolithic approach or migrate to a more modular architecture.
Decision
We decided to migrate from a monolithic structure to a modular architecture, organizing the system into the following modules:
- core: Shared core components
- masterdata: Master data management
- members: Member management
- horses: Horse registration
- events: Event management
- infrastructure: Shared infrastructure components
- client: Client applications
Each domain module (masterdata, members, horses, events) follows a clean architecture approach with separate API, application, domain, infrastructure, and service layers.
Consequences
Positive
- Improved maintainability: Smaller, focused modules are easier to understand and maintain
- Independent development: Teams can work on different modules with minimal coordination
- Selective scaling: Individual modules can be scaled based on their specific requirements
- Technology flexibility: Different modules can use different technologies as appropriate
- Clear boundaries: Domain boundaries are explicitly defined, improving the conceptual integrity of the system
Negative
- Increased complexity: The overall system architecture is more complex
- Deployment overhead: More components to deploy and manage
- Performance considerations: Inter-module communication adds latency
- Migration effort: Significant effort required to migrate from the monolithic structure
Neutral
- Team organization: Teams need to be reorganized around modules rather than features
- Documentation needs: More comprehensive documentation is required to understand the system as a whole
Alternatives Considered
Enhanced Monolith
We considered improving the internal structure of the monolith with better module boundaries but keeping it as a single deployable unit. This would have been simpler to deploy but wouldn't have addressed the scaling and technology flexibility issues.
Microservices
We considered a more fine-grained microservices approach with many smaller services. This would have provided maximum flexibility but introduced excessive complexity and operational overhead for our current needs.