En la actualidad, casi todo sistema requiere de un medio de persistencia, por lo general base de datos. La dependencia de los sistemas con la persistencia es tal que estos se construyen a partir de la base de datos. Se toman decisiones que favorecen las consultas y operaciones a base, pero que dejan muy anémico el modelado del sistema. La base de datos llega a tomar mucha importancia, demasiada, las entidades u objetos de acceso a datos se juntan con los componentes de conexión de base, se juntan preocupaciones y razones de fallo, sin mencionar la alta dependencia.
¿Qué busca Repository?.
Repository no es más que un sinónimo del principio de única responsabilidad de SOLID. La preocupación y responsabilidades de las entidades no deben ser acerca del medio de persistencia. En DDD todas las entidades son agnósticas del medio de persistencia, existen comportamientos específicos para las operaciones de persistencia que son responsabilidad de los repositorios. Este patrón también aplica en muchos sabores de MV* , arquitecturas de micro servicios o sistemas desacoplados.
Persistencia no implica ni SQL, tampoco base de datos.
El concepto de repositorio está pensado para no definir la base de datos como el elemento de persistencia por defecto, cualquier medio persistente vale para operar. Podrías construir repositorios de archivos de texto plano, Xml, JSON o cualquier otro medio persistente sin que la lógica de las reglas de negocio se vea afectada directamente. Esta es una poderosa herramienta que permite invertir dependencias y restar complejidad a la solución. También agrega holgura al desarrollo. Al tener un componente especializado en la comunicación con el medio persistente, cualquier cambio o diferencia puede ser absorbida por el repositorio, con esto se busca mantener la pureza de las reglas de negocio.
Desacoplar el origen de datos facilita el Testing.
El beneficio inmediato de separar los detalles de la lectura/escritura en persistencia es el tener más libertad para poder probar distintos escenarios. Uno de los desafíos más grandes en sistemas legados o con alto acoplamiento es reproducir escenarios para buscar errores o solo hacer debugging. Comúnmente en errores relacionados con bases de datos se modifican datos en tablas para poder reproducir escenarios de pruebas. Al desacoplar los componentes es más sencillo reproducir casos de pruebas creando fakes u orígenes de datos a medida.
Separar persistencia y entidades mejora la arquitectura de tus sistemas.
Los repositorios son una excelente práctica para mejorar la calidad de tus aplicaciones. Reducen problemas de integración del modelo de la base de datos con las reglas de negocio. Al tener un componente especializado en proporcionar las entidades al sistema, este puede absorber los cambios sin afectar las reglas de negocio, entidades o comportamientos.
También evita conocer demasiado acerca de la estructura de la base de datos. En lugar de generar un contexto desde el ORM donde todas las tablas y artefactos son visibles teóricamente, se produce un contexto limitado que previene romper algo por accidente. Esto es particularmente valiosos en bases de datos monolíticas de legados o en migraciones de monolíticos a micro servicios.
Un repositorio permite tomar decisiones arquitectónicas complejas más fácilmente, por ejemplo: cambiar el componente de acceso a datos puede ser una tarea costosa, o cambiar un query en código duro por un stored procedure.
Autor imagen: Bernhard Hanakam
Referencias:
- NVL in SQL Server - 2023-11-01
- ¿Que es Cake Build? - 2023-02-22
- #How to fix error: MSB4019: The imported project «Microsoft.Data.Tools.Schema.SqlTasks.targets» was not found - 2023-02-20
