Haz que el razonamiento perdure

Conserva el porqué, no solo el qué

Un registro de decisión de arquitectura (ADR, architecture decision record) es un documento pequeño que explica una elección con consecuencias.

Empieza por la situación y las restricciones, nombra la decisión y describe sus consecuencias. «Usar SQLite», sin más, pierde la razón. «Usar un solo almacén local duradero para un prototipo en un único servidor, para simplificar las transacciones; aceptar que el acceso de workers desde varios servidores obligará a revisar el diseño de almacenamiento» es más útil. Una decisión puede ser sensata en su contexto sin ser permanente. Guarda el registro cerca del código para revisar los cambios juntos.

Haz creíbles las alternativas

Compara dos o tres opciones realistas frente a los mismos impulsores.

Para el primer servicio de Relay, una cola respaldada por la base de datos puede ofrecer envíos atómicos con menos piezas móviles. Un broker (intermediario de mensajes) separado puede ofrecer funciones de entrega útiles, pero agrega operación y una frontera de consistencia. No le asignes desventajas absurdas a la opción rechazada para que la conclusión parezca inevitable.

Enuncia lo desconocido y la evidencia que tienes. Un prototipo corto o una prueba de falla suele valer más que una matriz llena de puntajes numéricos sin fundamento.

Revisa sin borrar la historia

Dale a los registros un estado, como propuesto, aceptado o reemplazado.

Cuando cambie una restricción, agrega un registro nuevo y enlaza el anterior, en lugar de reescribir la historia para que la decisión actual parezca inevitable. Define un disparador para reconsiderar, como contención demostrada, varios equipos independientes o un requisito que la frontera actual no puede cumplir. El disparador debe llevar a un análisis, no a una migración automática.

Incluye consecuencias favorables y adversas para que quienes mantengan el sistema entiendan las obligaciones que crea la elección.