ClinicCare
Plataforma HealthTech para la gestión clínica.
Plataforma Full-Stack orientada a la gestión clínica, construida con una arquitectura API-First y una estructura monorepo. El proyecto busca proporcionar una base sólida y mantenible para centralizar procesos clínicos y facilitar su evolución.
- API-First
- arquitectura
- 2
- aplicaciones principales
- 5+
- módulos de dominio
- Monorepo
- estructura del proyecto
Los sistemas de gestión clínica pueden crecer rápidamente en complejidad cuando frontend, backend y lógica de negocio se mezclan. ClinicCare parte de la necesidad de construir una base organizada que permita desarrollar funcionalidades clínicas manteniendo responsabilidades claras y facilitando el trabajo del equipo.
Se construyó una plataforma Full-Stack separando el frontend del backend mediante una API. El backend utiliza Django y Django REST Framework, mientras que el frontend está construido con Next.js y React. El proyecto se organiza como un monorepo utilizando pnpm y Turborepo para facilitar el trabajo colaborativo y la evolución del sistema.
Cómo está montado
Las capas de arriba abajo, con la tecnología concreta de cada una.
- 01
Interfaz
Aplicación construida con Next.js y React utilizando App Router. La estructura separa el ruteo, componentes, hooks, servicios, tipos y utilidades para mantener responsabilidades claras.
- 02
API
Backend construido con Django y Django REST Framework. La API funciona como punto de comunicación entre la interfaz y la lógica del sistema.
- 04
Persistencia
PostgreSQL actúa como base de datos principal para almacenar la información de la plataforma y sus diferentes dominios.
Qué elegí y qué descarté
- D01
API-First
La comunicación entre frontend y backend se diseña alrededor de una API, permitiendo mantener responsabilidades separadas y facilitando la evolución independiente de cada capa.
- D02
Arquitectura modular en el frontend
El frontend organiza el código por responsabilidades mediante app, components, hooks, services, types y lib. La estructura busca evitar complejidad innecesaria durante la etapa MVP y permitir una evolución progresiva.
- D03
Separación de responsabilidades
Los componentes se mantienen enfocados en la interfaz, mientras que los hooks gestionan comportamiento reutilizable y los services encapsulan la comunicación con la API.
- D04
No sobreingeniería
El proyecto evita introducir una arquitectura orientada a features antes de que exista una necesidad real. La estructura actual está diseñada para evolucionar cuando la complejidad del dominio lo justifique.
Retos y cómo se resolvieron
- 01
Mantener una arquitectura clara durante el MVP
Uno de los retos consiste en mantener una estructura suficientemente organizada para permitir trabajo paralelo y crecimiento futuro sin introducir abstracciones prematuras.
- 02
Separar correctamente las responsabilidades
La arquitectura establece reglas claras para que los componentes, hooks, servicios y API mantengan responsabilidades diferentes y las dependencias fluyan en una sola dirección.
- 03
Preparar el sistema para crecer
La estructura actual busca permitir una futura evolución hacia una organización basada en features cuando los dominios del sistema alcancen la complejidad necesaria.