1.8 KiB
1.8 KiB
Future Improvements
This document tracks architectural improvements and refactoring opportunities identified during development.
Architecture Refactoring
Repository + Service Pattern Migration
Current State: Using Active Record pattern where TaskModel handles its own persistence and HTTP handlers contain business logic directly.
Future Improvement: Migrate to Repository + Service pattern for better separation of concerns:
// Repository trait for data access abstraction
trait TaskRepository {
async fn create(&self, task: &NewTask) -> Result<Task>;
async fn find_by_id(&self, id: Uuid) -> Result<Option<Task>>;
async fn update(&self, task: &Task) -> Result<Task>;
async fn delete(&self, id: Uuid) -> Result<()>;
async fn list_all(&self) -> Result<Vec<Task>>;
}
// Service layer for business logic
struct TaskService {
repository: Box<dyn TaskRepository>,
}
impl TaskService {
async fn create_task(&self, title: String, description: Option<String>) -> Result<Task> {
// Input validation
// Business rules (e.g., auto-set completed_at when status changes)
// Call repository
}
}
Benefits:
- Better testability through repository mocking
- Centralized business logic in service layer
- Cleaner separation between data access, business logic, and HTTP handling
- Easier to add complex business rules as the application grows
Implementation Plan:
- Create TaskRepository trait and SqliteTaskRepository implementation
- Move database operations from TaskModel to repository
- Create TaskService with business logic
- Update HTTP handlers to use services instead of models directly
- Add comprehensive unit tests for service layer with mocked repositories
Priority: Medium - Good for maintainability as the codebase grows, but current Active Record pattern works fine for MVP scope.