ADR  - 000001-Microservicios

Estado

Partes interesadas


AREA GOBIERNO TECNOLOGICO DESARROLLO SOFTWARE ASISTENCIAL (NTTDATA) DESARROLLO SOFTWARE ECONOMICO-FINANCIERO (NTTDATA) DESARROLLO SOFTWARE RRHH (AYESA) 


TAGS


Tomada el

03/11/2023

Responsable

LUIS MARTINEZ FONTIVEROS CARLOS GONZALEZ SANTIAGO 

Documentación Asociada

Patrón Repositorio y especificación - Martin Fowler

Patrón Repositorio - Martín Fowler

Solución Afectada

N/A


Responsable

Aprobado por

Consultados

Informados

LUIS MARTINEZ FONTIVEROS CARLOS GONZALEZ SANTIAGO 

DESARROLLO SOFTWARE ASISTENCIAL (NTTDATA) DESARROLLO SOFTWARE RRHH (AYESA) DESARROLLO SOFTWARE ECONOMICO-FINANCIERO (NTTDATA) 


Asunto a Decidir

El objetivo de este ADR es establecer los patrones de diseño y arquitectónicos a implementar en las solucionesCriterios:
  • Que sea una solución estandarizada o al menos un estándar de facto dentro de la comunidad de desarrollo e ingeniería de software
  • Multitecnología - Que encaje con diferentes tipos de orígenes de datos (RBDM, NOSQL,FILE,HTTP, etc)
  • Sostenible
  • Alineado con la arquitectura de referencia de contenedores.
    • Como encaja con la arquitectura de microservicios
    • Como encaja con clean Architecture
    • Como encaja con el desarrollo con una filosofía basada en DDD
  • Independiente al resto de capas del microservicio

Identificación de la decisión

Describe brevemente la decisión arquitectónica tomada.

Contexto

Para facilitar las implementaciones dentro de esta transformación tecnológica, se busca definir un patrón común para desarrollar la capa de acceso a datos, con el objetivo de que sea reconocible por cualquier proveedor, y en cualquier aplicación.
Esto permitirá al SAS, afrontar con mayores garantías situaciones como el mantenimiento de una funcionalidad, sus evolutivos, el cambio de los desarrolladores entre proyectos, la incorporación de nuevos desarrolladores o cambios de proveedor.


  • Descripción: Centraliza el acceso a los datos y proporciona una abstracción de las operaciones CRUD (Crear, Leer, Actualizar, Eliminar) sobre las entidades del dominio.
  • Ventajas: Separa la lógica de negocio del acceso a los datos, facilita las pruebas unitarias y permite cambiar la fuente de datos sin modificar el código del dominio.
  • Pros:
    • Abstracción de operaciones CRUD.
    • Facilita pruebas unitarias.
    • Desacopla la lógica de negocio de la lógica de persistencia.
  • Contras:
    • Puede volverse demasiado genérico.
    • Puede introducir una capa adicional de complejidad.
  • Encaje en arquitecturas:
    • Microservicios: Ideal para encapsular la lógica de acceso a datos dentro de cada servicio.
    • Clean Architecture: Repositorios como interfaces en la capa de dominio, con implementaciones en la capa de infraestructura.
    • DDD: Repositorios representan colecciones de agregados, manteniendo el enfoque en el dominio.



Especifica la opción elegida y explica las razones detrás de esa elección.
Detalla las implicaciones de la decisión tomada, tanto positivas como negativas, y cómo afectará al sistema a nivel arquitectónico.
Actualiza el estado actual de la decisión y si ha habido algún cambio o evolución.