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
69 lines
3.1 KiB
Markdown
69 lines
3.1 KiB
Markdown
# 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:
|
|
|
|
1. The codebase became difficult to maintain and understand
|
|
2. Development teams had to coordinate closely, slowing down development
|
|
3. Scaling the entire application was necessary even when only specific parts needed more resources
|
|
4. 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.
|
|
|
|
## References
|
|
|
|
- [Migration notes in README.md](../../../../README.md#aktuelle-migrationshinweise)
|
|
- [Modular Monoliths by Simon Brown](https://simonbrown.je/blog/modularity-and-microservices/)
|
|
- [Clean Architecture by Robert C. Martin](https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html)
|