Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Proceso de ADR
Un registro de decisiones de arquitectura (ADR) es un documento que describe la elección que hace el equipo sobre un aspecto importante de la arquitectura de software que planea crear. Cada ADR describe la decisión de arquitectura, su contexto y sus consecuencias. Los ADR tienen estados y, por lo tanto, siguen un ciclo de vida. Para ver un ejemplo de un ADR, consulte el apéndice.
El proceso de ADR genera un conjunto de registros de decisiones de arquitectura. Este conjunto crea el registro de decisiones. El registro de decisiones brinda el contexto del proyecto, así como información detallada sobre la implementación y el diseño. Los miembros del proyecto leen por encima los títulos de cada ADR para obtener información general sobre el contexto del proyecto. Leen los ADR para profundizar en las implementaciones de los proyectos y las opciones de diseño.
Cuando el equipo acepta un ADR, este no se puede modificar. Si los conocimientos nuevos requieren una decisión diferente, el equipo propone un ADR nuevo. Cuando el equipo acepta el ADR nuevo, reemplaza al ADR anterior.
Alcance del proceso de ADR
Los miembros del proyecto deben crear un ADR para cada decisión importante desde el punto de vista de la arquitectura que afecte al proyecto o producto de software, incluido lo siguiente (Richards y Ford (2020)):
-
Estructura (por ejemplo, patrones como los microservicios)
-
Requisitos no funcionales (seguridad, alta disponibilidad y tolerancia a errores)
-
Dependencias (acoplamiento de componentes)
-
Interfaces (API y contratos publicados)
-
Técnicas de creación (bibliotecas, marcos, herramientas y procesos)
Los requisitos funcionales y no funcionales son los aportes más habituales al proceso de ADR.
Contenidos de un ADR
Cuando el equipo identifica la necesidad de un ADR, un miembro del equipo comienza a redactarlo en función de una plantilla para todo el proyecto. (Consulte la Organización de ADR en GitHub
Proceso de adopción de un ADR
Todos los miembros del equipo pueden crear un ADR, pero el equipo debe establecer una definición de propiedad del ADR. Cada autor propietario de un ADR debe mantener y comunicar el contenido del ADR de forma activa. Para aclarar esta propiedad, en esta guía se hace referencia a los autores de los ADR como propietarios de un ADR en las siguientes secciones. Otros miembros del equipo siempre pueden contribuir a un ADR. Si el contenido de un ADR cambia antes de que el equipo lo acepte, el propietario debe aprobar estos cambios.
En el siguiente diagrama. se ilustra el proceso de creación, propiedad y adopción del ADR.
Una vez que el equipo identifica una decisión de arquitectura y a su propietario, el propietario del ADR brinda el ADR en el estado Propuesto al inicio del proceso. Los ADR en el estado Propuesto se encuentran listos para su revisión.
Luego, el propietario del ADR inicia el proceso de revisión del ADR. El objetivo del proceso de revisión del ADR es decidir si el equipo acepta el ADR, determina que es necesario volver a elaborarlo o lo rechaza. El equipo del proyecto, incluido el propietario, revisa el ADR. La reunión de revisión debe comenzar con un intervalo de tiempo dedicado a la lectura del ADR. En promedio, de 10 a 15 minutos deberían ser suficientes. Durante este tiempo, cada miembro del equipo lee el documento y agrega comentarios y preguntas para señalar los temas que no están claros. Tras la fase de revisión, el propietario del ADR lee y analiza cada comentario con el equipo.
Si el equipo encuentra puntos de acción para mejorar el ADR, el estado del ADR se mantiene en Propuesto. El propietario del ADR formula las acciones y, en colaboración con el equipo, asigna un responsable a cada acción. Cada miembro del equipo puede contribuir y resolver los puntos de acción. Reprogramar el proceso de revisión es responsabilidad del propietario del ADR.
El equipo también puede decidir rechazar el ADR. En este caso, el propietario del ADR agrega un motivo de rechazo para evitar futuras discusiones sobre el mismo tema. El propietario cambia el estado del ADR a Rechazado.
Si el equipo aprueba el ADR, el propietario agrega una marca de tiempo, una versión y una lista de las partes interesadas. Luego, el propietario actualiza el estado a Aceptado.
Los ADR y el registro de decisiones que crean representan las decisiones tomadas por el equipo y proporcionan un historial de todas las decisiones. Siempre que es posible, el equipo utiliza los ADR como referencia durante las revisiones del código y la arquitectura. Además de revisar el código y realizar tareas de diseño e implementación, los miembros del equipo deben consultar los ADR a fin de tomar decisiones estratégicas para el producto.
En el siguiente diagrama, se muestra el proceso de aplicación de un ADR para validar si un cambio en un componente de software se ajusta a las decisiones acordadas.
Como práctica recomendada, cada cambio en el software debe pasar por una revisión de pares y requiere al menos una aprobación. Durante la revisión del código, el revisor del código podría detectar cambios que infrinjan uno o más ADR. En este caso, el revisor pide al autor del cambio en el código que actualice el código y comparte un enlace al ADR. Cuando el autor actualiza el código, los pares encargados de la revisión lo aprueban e incorporan a la base del código principal.
Proceso de revisión de un ADR
El equipo debe tratar los ADR como documentos que no se pueden modificar después de aceptarlos o rechazarlos. Los cambios en un ADR existente requieren que se cree un ADR nuevo, se establezca un proceso de revisión para el ADR nuevo y se apruebe el ADR. Si el equipo aprueba el ADR nuevo, el propietario debe cambiar el estado del ADR anterior a Sustituido. En el diagrama siguiente, se ilustra el proceso de actualización.
