Backend Architecture in ROAR
ROAR implements a Repository Pattern Architecture (also known as Clean Architecture) to establish a clear separation of concerns and maintain scalable data operations.
Core Principles
Dependency Injection
The architecture leverages dependency injection to achieve loose coupling between components. Dependencies are supplied through interfaces, enabling:
- Easier unit testing through dependency mocking
- Flexible component replacement without affecting the broader application
- Clear contract definitions between components
Dependency Inversion Principle (DIP)
Following DIP, high-level modules don't depend on low-level modules - both depend on abstractions. This is implemented through interfaces that define component contracts, with concrete classes providing the actual implementations.
Architectural Layers
1. Domain (Model) Layer
Defines the core business entities and their behaviors through interfaces. These models establish contracts for data operations throughout the application.
Core Domain Models:
- Administration
- Assignment
- Class
- District
- Family
- Identity Provider
- Group
- Legal
- Run
- School
- Score
- Task
- Trial
- User Claim
- User
- Variant
2. Repository Layer
Acts as a data access abstraction layer that:
- Encapsulates data access logic
- Provides a consistent interface regardless of data source
- Maintains single responsibility per entity
- Defines explicit contracts between frontend and backend
- Handles CRUD operations for specific entities
3. Service Layer
Implements business logic by:
- Orchestrating operations across repositories
- Processing domain entities
- Remaining data source agnostic
- Enforcing business rules and workflows
- Coordinating complex operations across multiple repositories
4. Controller Layer
Manages HTTP communication by:
- Handling incoming API requests
- Validating request data
- Coordinating with appropriate services
- Formatting API responses
- Maintaining REST best practices
Benefits
This architecture provides:
- Clear separation of concerns
- Improved testability
- Flexible data source switching
- Scalable and maintainable codebase
- Consistent data access patterns