Saltar a contenido

ADR-001: Adopcion de Clean Architecture

Estado: PROPUESTO Fecha: 2025-12-07 Autor: ArchitectureDrone (MTS-DRN-ARC-001) Revisores: SpecQueen, Director

1. Contexto

MedTime es un sistema de gestion de medicamentos que maneja informacion de salud protegida (PHI) y debe cumplir con regulaciones estrictas (HIPAA, FDA 21 CFR Part 11). El sistema necesita:

  1. Mantenibilidad: El codigo debe ser facil de modificar y extender
  2. Testeabilidad: Cobertura de tests robusta para cumplir compliance
  3. Independencia de frameworks: Flexibilidad para cambiar tecnologias
  4. Offline-first: Funcionamiento sin conexion en dispositivos moviles
  5. Multi-plataforma: iOS, Android, y potencialmente web

2. Decision

Adoptamos Clean Architecture como patron arquitectonico principal para todas las aplicaciones cliente (iOS y Android) y servicios backend.

2.1. Estructura de Capas

┌─────────────────────────────────────────┐
│           PRESENTATION                   │
│  (Views, ViewModels, UI State)          │
├─────────────────────────────────────────┤
│              DOMAIN                      │
│  (Entities, Use Cases, Repository       │
│   Interfaces)                           │
├─────────────────────────────────────────┤
│               DATA                       │
│  (Repository Impl, Data Sources,        │
│   DTOs, Mappers)                        │
└─────────────────────────────────────────┘

2.2. Regla de Dependencias

Las dependencias SOLO apuntan hacia adentro (hacia Domain):

  • Presentation depende de Domain
  • Data depende de Domain
  • Domain NO depende de nada externo

3. Consecuencias

3.1. Positivas

  • Alta testeabilidad: Domain layer 100% testeable sin mocks de framework
  • Flexibilidad: Cambiar UI o DB sin afectar logica de negocio
  • Claridad: Separacion clara de responsabilidades
  • Onboarding: Estructura predecible para nuevos desarrolladores
  • Compliance: Facilita auditorias de codigo para HIPAA/FDA

3.2. Negativas

  • Boilerplate inicial: Mas codigo para features simples
  • Curva de aprendizaje: Requiere entender el patron
  • Over-engineering riesgo: Para features triviales puede ser excesivo

3.3. Riesgos

  • Implementacion inconsistente: Sin revisiones de codigo, puede desviarse
  • Mitigacion: Code reviews obligatorios, linting, arquitectura tests

4. Alternativas Consideradas

4.1. MVC/MVVM Simple

  • Rechazado porque: Acopla UI con logica de negocio, dificulta testing

4.2. VIPER

  • Rechazado porque: Demasiado complejo, mas boilerplate que Clean Architecture

4.3. Redux/MVI

  • Rechazado porque: Mas apropiado para estados globales complejos, no para nuestro caso

5. Referencias

ADR generado por ArchitectureDrone - IT-01