# 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:

```rust
// 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**:
1. Create TaskRepository trait and SqliteTaskRepository implementation
2. Move database operations from TaskModel to repository
3. Create TaskService with business logic
4. Update HTTP handlers to use services instead of models directly
5. 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.