Skip to main content

PL02: Registro de decisiones arquitectónicas

Última edición: August 30, 2025 10:47 AM Propietario: Daniel Queijeiro Albo Etiquetas: Plantilla Fecha de creación: August 26, 2025 9:59 PM

Esta plantilla permite documentar de manera clara y estandarizada las decisiones arquitectónicas tomadas en los proyectos de software. Facilita la trazabilidad, la comunicación entre equipos y el entendimiento del contexto que llevó a tomar cada decisión.

🎯 Objetivo​

  • Registrar y justificar las decisiones arquitectónicas clave de los proyectos.
  • Asegurar que las decisiones tengan un contexto claro, impulsores identificados y consecuencias documentadas.
  • Mejorar la transparencia y la colaboración.

Título de la decisión arquitectónica​

  • Status: Aceptado | Borrador | Rechazado | Obsoleto
  • Encargados: Personas involucradas en la decisión
  • Fecha: DD-MM-YYYY

Contexto y problema​

Una breve explicación acerca del problema a resolver.

Impulsores de decisiones​

Lista de cosas que necesitas considerar para elegir una opción.

Opciones consideradas​

Lista de las opciones con una pequeña descripción, ventajas y desventajas de usar cada opción.

Resultado de la decisión​

Explicación acerca de cuál opción fue seleccionada.

Consecuencias positivas​

Lista de consecuencias positivas que introduce la opción seleccionada.

Consecuencias negativas​

Lista de consecuencias negativas que introduce la opción seleccionada.

Lista de recursos relevantes para aprender de cada opción.

📝 Ejemplos​

✅ Correcto​

Migrar a EJS​

  • Status: Aceptado
  • Encargados: Daniel Queijeiro Albo (Arquitecture Owner)
  • Fecha: 19-05-2025

Contexto y problema​

La forma en que implementamos nuestra navegación entre vistas en ElectronJS originalmente está dificultando mucho el desarrollo de requisitos funcionales.

Hicimos una prueba de concepto y, si implementamos EJS en la lógica de carga de vistas, se puede acelerar el desarrollo, pero esto implica:

  1. Crear una forma reutilizable de precargar los EJS (ya que ElectronJS solo carga HTML).
  2. Refactorizar todas las vistas a formato EJS.
  3. Adaptar todos los scripts a la nueva forma de cargar vistas.

Impulsores de decisiones​

  • ¿Cuánto nos va a eficientar realmente la migración a EJS?
  • ¿Es viable hacer una migración tan tarde en el proyecto?
  • ¿Es mejor solo seguir con HTML?

Opciones consideradas​

Opción 1: EJS​

Motor de plantillas que permite generar HTML dinámico usando JavaScript y sintaxis embebida.

  • Ventajas:
    • Permite reutilización de componentes y layouts.
    • Sintaxis familiar para desarrolladores JavaScript.
    • Facilita la inyección de datos dinámicos.
    • Reduce duplicación de código HTML.
    • Mejor mantenibilidad del código.
  • Desventajas:
    • Requiere configuración adicional en ElectronJS.
    • Necesita refactorización completa de vistas existentes.
    • Curva de aprendizaje para el equipo.
    • Dependencia adicional en el proyecto.

Opción 2: HTML estático​

Continuar con archivos HTML como se implementó originalmente.

  • Ventajas:
    • No requiere cambios en la arquitectura actual.
    • Funciona directamente con ElectronJS.
    • Sin curva de aprendizaje adicional.
  • Desventajas:
    • Alta duplicación de código.
    • Dificultad para mantener consistencia en la UI.
    • Desarrollo más lento de nuevas características.
    • Navegación entre vistas compleja.

Resultado de la decisión​

Se decidió migrar a EJS, ya que nos ayudará a acelerar el desarrollo y liberar el MVP más rápido. Vemos más viable dedicar una semana a refactorizar que continuar con la complejidad del HTML actual.

Consecuencias positivas​

  • Aceleración significativa en el desarrollo de nuevas vistas.
  • Mejor reutilización de componentes UI (headers, footers, menús).
  • Código más mantenible y organizado.
  • Facilita la implementación de temas y estilos consistentes.
  • Reducción de duplicación de código.
  • Mayor flexibilidad para inyectar datos dinámicos.

Consecuencias negativas​

  • Tiempo invertido en la refactorización (aprox. 1 semana).
  • Posibles bugs durante la migración.
  • Complejidad adicional en el proceso de build.
  • Dependencia nueva que debe ser mantenida.
  • Posible impacto en rendimiento por el renderizado.

❌ Incorrecto​

Migrar a EJS​

  • Status: Aprobado
  • Encargados: Equipo
  • Fecha: 2025

Contexto y problema​

Necesitamos algo mejor para las vistas porque no sabemos trabajar con lo que tenemos.

Impulsores de decisiones​

  • Que funcione.
  • Que sea rápido.

Opciones consideradas​

EJS​

Sirve para plantillas.

HTML​

Es lo que ya tenemos.

Resultado de la decisión​

Elegimos EJS porque sí.

Consecuencias positivas​

  • Mejor.

Consecuencias negativas​

  • Tarda.

Google.

📎 Recursos relacionados​