22. Repositorios conceptuales: recuperación y persistencia sin mezclar tecnología
22.1 Introducción
En un sistema real, los objetos del dominio no viven solo en memoria. Deben recuperarse, guardarse, actualizarse y encontrarse cuando una operación los necesita. Sin embargo, durante el modelado de dominio conviene separar esa necesidad conceptual de los detalles técnicos de almacenamiento.
Un repositorio conceptual representa una colección de agregados o entidades importantes del dominio. Permite expresar que el modelo necesita obtener o guardar ciertos objetos sin hablar todavía de tablas, consultas SQL, archivos, servicios externos o frameworks.
22.2 Imagen conceptual de repositorio
22.3 Qué es un repositorio conceptual
Un repositorio conceptual es una abstracción del dominio que permite recuperar y persistir agregados o entidades raíz. Se piensa como una colección de objetos del negocio, no como una tabla de base de datos.
Por ejemplo, Repositorio de turnos, Repositorio de pacientes, Repositorio de agendas o Repositorio de pedidos pueden aparecer cuando el dominio necesita localizar esos agregados para ejecutar operaciones.
22.4 Repositorio no significa tabla
Un repositorio no debe confundirse con una tabla. Una tabla es una estructura técnica de persistencia. Un repositorio conceptual representa una forma de acceder a objetos del dominio con significado.
Un agregado Pedido puede almacenarse en varias tablas, en un documento, en eventos o en un servicio externo. Desde el modelo conceptual, lo importante es que existe una forma de recuperar un Pedido por su identidad y guardar sus cambios respetando el dominio.
22.5 Repositorio y raíz de agregado
Los repositorios suelen trabajar con raíces de agregado. Si Pedido es raíz, el repositorio recupera Pedidos completos en el sentido necesario para proteger sus reglas. No debería exponer libremente entidades internas como Ítems de pedido para modificarlas por fuera de la raíz.
Esto mantiene el límite del agregado. El acceso externo busca la raíz, ejecuta operaciones de dominio sobre ella y luego conserva los cambios.
22.6 Recuperar por identidad
Una función habitual de un repositorio conceptual es recuperar un agregado por su identidad. Por ejemplo: buscar un Turno por número de turno, una Agenda por identificador, un Paciente por historia clínica o un Pedido por número de pedido.
La identidad usada debe tener sentido para el dominio o estar claramente definida como identificador interno. Lo importante es que el repositorio permite localizar el objeto que participará en una operación.
22.7 Guardar cambios
Otra función habitual es conservar los cambios de un agregado después de una operación válida. Por ejemplo, luego de cancelar un turno, publicar una agenda o confirmar un pedido, el sistema necesita persistir el nuevo estado.
En el modelo conceptual no hace falta decidir si se usará una base relacional, un documento JSON o un servicio remoto. Esa decisión pertenece a la implementación. El modelo solo debe indicar la necesidad de persistir agregados relevantes.
22.8 Consultas de búsqueda
Además de recuperar por identidad, puede haber consultas de búsqueda: turnos disponibles, pacientes por documento, agendas de un profesional, pedidos pendientes o facturas emitidas en un período.
No todas las consultas deben vivir necesariamente en el mismo repositorio conceptual. Algunas consultas son parte del dominio y otras son necesidades de presentación o reportes. Conviene distinguir cuándo la búsqueda participa en una regla de negocio y cuándo solo alimenta una pantalla o informe.
22.9 Repositorio frente a servicio de dominio
Un repositorio recupera y conserva objetos del dominio. Un servicio de dominio aplica una operación o política del negocio. Mezclar ambos conceptos puede generar confusión.
Por ejemplo, un Repositorio de agendas puede obtener una agenda. Un Calculador de disponibilidad puede usar esa agenda junto con turnos, especialidad y bloqueos para determinar horarios disponibles. El repositorio no debería convertirse en el lugar donde se esconden reglas del negocio.
22.10 Repositorio frente a DAO o consulta técnica
En diseño técnico existen patrones como DAO, mapper, ORM o consultas específicas. Pueden ser útiles, pero no son lo mismo que un repositorio conceptual. El repositorio pertenece al lenguaje del dominio; los mecanismos técnicos pertenecen a infraestructura.
Durante el análisis, nombres como Repositorio de turnos o Repositorio de pedidos son aceptables si expresan colecciones del negocio. Nombres como TablaTurnosDAO o QueryBuilderTurnos ya mezclan detalles técnicos.
22.11 Mantener el dominio limpio
La idea de repositorio ayuda a mantener el dominio limpio de detalles tecnológicos. El modelo puede hablar de recuperar Paciente, guardar Turno o buscar Agenda sin depender de cómo se implementa esa operación.
Esto permite que el análisis siga enfocado en reglas y significados. La tecnología se decidirá luego, cuando se diseñe la solución técnica.
22.12 Ejemplo: cancelar turno
Para cancelar un turno, el sistema puede necesitar:
- Recuperar el Turno desde un repositorio conceptual.
- Validar si el Turno puede cancelarse según su estado.
- Aplicar la política de cancelación correspondiente.
- Cambiar el estado del Turno o registrar una Cancelación.
- Guardar los cambios del agregado.
La recuperación y persistencia son necesarias, pero no deben ocultar las reglas centrales de cancelación.
22.13 Tabla de ejemplos
La siguiente tabla muestra repositorios conceptuales posibles:
| Repositorio conceptual | Agregado o entidad raíz | Uso principal |
|---|---|---|
| Repositorio de turnos | Turno | Recuperar turnos para reservar, cancelar o registrar atención. |
| Repositorio de agendas | Agenda | Obtener agendas para publicar, bloquear o consultar disponibilidad. |
| Repositorio de pacientes | Paciente | Buscar pacientes por identidad o datos relevantes. |
| Repositorio de pedidos | Pedido | Recuperar pedidos para confirmar, cancelar o cambiar estado. |
| Repositorio de facturas | Factura | Localizar facturas emitidas, pagadas o anuladas. |
22.14 Preguntas para definir repositorios
Estas preguntas ayudan a identificar repositorios conceptuales:
- ¿Qué agregados necesita recuperar el dominio para ejecutar operaciones?
- ¿Qué entidad raíz representa cada colección?
- ¿Qué búsquedas tienen significado para el negocio?
- ¿Qué cambios deben persistirse después de una operación válida?
- ¿Estamos accediendo a una raíz de agregado o a una entidad interna?
- ¿La consulta pertenece al dominio o solo a una pantalla o reporte?
- ¿El nombre del repositorio usa lenguaje del dominio o lenguaje técnico?
22.15 Errores frecuentes
Al modelar repositorios, suelen aparecer estos errores:
- Confundir repositorio conceptual con tabla de base de datos.
- Usar nombres técnicos que mezclan infraestructura con dominio.
- Permitir modificar entidades internas de un agregado desde repositorios separados.
- Colocar reglas de negocio dentro de consultas de persistencia.
- Crear repositorios para cada clase sin analizar agregados ni raíces.
- No distinguir consultas del dominio de consultas de presentación.
- Diseñar repositorios pensando primero en el motor de base de datos.
22.16 Qué debes recordar de este tema
- Un repositorio conceptual permite recuperar y persistir objetos del dominio.
- No es una tabla ni un detalle de infraestructura.
- Suele trabajar con raíces de agregado.
- Ayuda a mantener separado el dominio de la tecnología de almacenamiento.
- No debería ocultar reglas de negocio dentro de consultas técnicas.
- Las búsquedas deben analizarse según su significado para el dominio.
- Los nombres deben usar lenguaje ubicuo y no vocabulario de base de datos.
22.17 Conclusión
Los repositorios conceptuales permiten expresar una necesidad real del dominio: recuperar y conservar agregados importantes sin contaminar el modelo con detalles tecnológicos. Son una frontera útil entre el conocimiento del negocio y la infraestructura que finalmente almacenará los datos.
En el próximo tema estudiaremos los contextos delimitados, una herramienta clave para separar significados cuando distintas áreas del negocio usan conceptos parecidos de forma diferente.