Estás viendo una versión antigua de esta página. Ve a la versión actual.

Comparar con el actual Ver el historial de la página

Versión 1 Siguiente »



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.

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.


Alternativas Consideradas
Specification Pattern
  • 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.
Decisión Tomada

Describe brevemente la decisión arquitectónica tomada.

Especifica la opción elegida y explica las razones detrás de esa elección.
Consecuencias

Describe brevemente la decisión arquitectónica tomada.

Detalla las implicaciones de la decisión tomada, tanto positivas como negativas, y cómo afectará al sistema a nivel arquitectónico.
Estado Actual

Describe brevemente la decisión arquitectónica tomada.

Actualiza el estado actual de la decisión y si ha habido algún cambio o evolución.
  • Sin etiquetas