Saltar a contenido

Bounded Contexts - Sistema de Reservas de Turnos Medicos

Proposito

Mapa de los bounded contexts del sistema. Define los limites claros entre subdominios y como se comunican entre si.

Cuando usarlo

  • Para entender la separacion de responsabilidades del sistema.
  • Al decidir donde vive una nueva feature.
  • Para planificar integraciones entre contextos.

1. Mapa de Contextos

+---------------------+       +---------------------+
|                     |       |                     |
|    Identity &       |       |    Scheduling       |
|    Access           |       |    (Reservas)       |
|                     |       |                     |
|  - Registro         |       |  - Disponibilidad   |
|  - Login/Auth       +------>+  - Reserva de turno  |
|  - Roles            |       |  - Cancelacion      |
|  - Passwords        | User  |  - Penalizaciones   |
|                     | ID    |                     |
+---------------------+       +----------+----------+
                                         |
                                         | BookingConfirmed
                                         | BookingCancelled
                                         v
+---------------------+       +---------------------+
|                     |       |                     |
|    Clinic           |       |    Notification     |
|    Management       |       |                     |
|                     |       |  - Email confirm.   |
|  - Clinicas         +------>+  - Recordatorios    |
|  - Especialidades   | Clinic|  - Alertas medico   |
|  - Configuracion    | Info  |                     |
|                     |       |                     |
+---------------------+       +---------------------+

2. Descripcion de Cada Contexto

2.1 Identity & Access (Identidad y Acceso)

Responsabilidad: Gestionar la identidad de los usuarios, autenticacion, y autorizacion.

Incluye: - Registro de pacientes - Login / logout - Gestion de passwords - Roles y permisos (PATIENT, DOCTOR, ADMIN) - JWT tokens

NO incluye: - Datos especificos de medicos (matricula, especialidades) -> eso es Clinic Management. - Logica de reservas -> eso es Scheduling.

Entidades clave: User, RefreshToken, PasswordHistory

Dueño: Equipo de Backend (Maria Lopez)

2.2 Scheduling (Reservas)

Responsabilidad: Todo lo relacionado con la reserva, cancelacion, y gestion de turnos.

Incluye: - Configuracion de disponibilidad del medico - Busqueda de slots disponibles - Reserva de turnos - Cancelacion con politica de penalizacion - Bloqueo de dias

NO incluye: - Datos de autenticacion -> Identity & Access. - Datos de la clinica (direccion, nombre) -> Clinic Management. - Envio de notificaciones -> Notification.

Entidades clave: Booking, DoctorAvailability, BlockedDate, TimeSlot (calculado)

Dueño: Equipo de Backend (Carlos Ramirez)

2.3 Clinic Management (Gestion de Clinicas)

Responsabilidad: Administracion de clinicas, medicos, y especialidades.

Incluye: - CRUD de clinicas - CRUD de especialidades - Asignacion de medicos a clinicas - Perfil profesional del medico (matricula, especialidades, foto)

NO incluye: - Disponibilidad horaria del medico -> eso es Scheduling. - Autenticacion del medico -> Identity & Access.

Entidades clave: Clinic, Doctor, Specialty, DoctorClinicAssignment

Dueño: Equipo de Backend (Carlos Ramirez)

2.4 Notification (Notificaciones)

Responsabilidad: Envio de comunicaciones a usuarios.

Incluye: - Emails de confirmacion de turno - Emails de cancelacion - Recordatorios (24h antes del turno) - Notificaciones al medico de nuevas reservas

NO incluye: - Decidir CUANDO notificar -> los otros contextos emiten eventos. - Logica de negocio de turnos -> Scheduling.

Entidades clave: NotificationTemplate, NotificationLog

Dueño: Equipo de Backend / DevOps

3. Relaciones entre Contextos

Upstream Downstream Tipo Mecanismo Que se comparte
Identity & Access Scheduling Customer/Supplier User ID en JWT ID del usuario, rol
Clinic Management Scheduling Customer/Supplier API interna Doctor ID, Clinic ID, Specialty ID
Scheduling Notification Publisher/Subscriber Domain Events (cola) BookingConfirmed, BookingCancelled con datos del turno
Clinic Management Notification Customer/Supplier API interna Nombre del medico, nombre de la clinica para el email

4. Reglas de Integracion

  1. Cada contexto tiene su propia base de datos logica (en v1 pueden compartir BD fisica pero schemas/tablas separados).
  2. Los contextos se comunican via eventos o APIs internas, nunca accediendo directamente a las tablas de otro contexto.
  3. Cada contexto puede evolucionar independientemente siempre que respete los contratos establecidos.
  4. Los IDs se comparten entre contextos (ej: User ID), pero los datos detallados se consultan al contexto dueño.

5. Contextos Futuros (No implementados)

Contexto Responsabilidad Cuando
Billing Pagos, facturacion, obras sociales v2
Telemedicine Videollamadas, sala de espera virtual v2
Clinical Records Historia clinica, recetas v3
Analytics Dashboards, reportes, metricas de negocio v2

Checklist de Completitud

  • Todos los contextos actuales identificados
  • Responsabilidades claras (incluye / no incluye)
  • Relaciones entre contextos documentadas
  • Mecanismos de comunicacion definidos
  • Contextos futuros listados
  • Revisada por otro ingeniero

Archivos relacionados