pkasarda/arquitectura-robusta

Arquitectura Robusta

Produce el diseño más pequeño cuyas garantías puedan explicarse y cuestionarse. Las reglas guían las decisiones; no certifican corrección. Una arquitectura útil hace explícitos los hechos importantes, da a las reglas un hogar con autoridad y sigue siendo comprensible cuando algo falla o cambia.

Empieza desde una consecuencia

Para un sistema existente, inspecciona los puntos de entrada reales, llamadores, almacenes de estado y validaciones antes de confiar en diagramas o propuestas anteriores. Para un sistema nuevo, distingue requisitos de suposiciones; describe el primer flujo real antes de elegir componentes.

Registra solo las restricciones que cambian una decisión: usuarios y autoridad, volumen de operación, latencia o presupuestos de recursos, disponibilidad, condiciones de fallo, necesidades de recuperación y durabilidad, restricciones de despliegue y lo que el equipo puede operar. Pregunta por la elección de producto faltante cuando esta cambie la corrección. Continúa el trabajo independiente y reversible mientras esa elección no esté resuelta.

Calibra la intervención:

• Brecha de modelo/ownership: el hecho necesario, la operación completa o la autoridad consistente está ausente o dividida. Resuelve ese contrato antes de parchear sus lectores.
• Defecto de límite: existe un dueño adecuado pero un llamador lo elude o su aplicación es incompleta. Profundiza o usa ese dueño; un defecto entre capas no requiere por sí mismo una nueva arquitectura.
• Brecha de producto: el comportamiento requerido no está decidido. Presenta la consecuencia concreta y las opciones más pequeñas, en lugar de elegir silenciosamente.
• Defecto de presentación/local: los hechos subyacentes son correctos pero necesitan una representación, análisis o corrección de copia local. Aplica la corrección local normal; detén aquí el flujo de trabajo arquitectónico.

Un archivo grande, sintaxis duplicada, la falta de un nombre de patrón o un paquete propuesto no es por sí solo evidencia de una brecha de modelo.

Para diseños o revisiones que involucren acceso a recursos protegidos, aplica autorización si está instalada. Esta es la dueña del recorrido de la política de acceso; mantén las reglas locales de propiedad y confianza a continuación cuando uses esta habilidad sola.

Da a los hechos y reglas un hogar

Nombra el hecho o invariante, su autoridad lógica y las operaciones permitidas para cambiarlo. La autoridad puede ser una función local, un publicador de archivo, un manejador de librería, un proceso o servicio; no necesita ser un servidor o un módulo nuevo.

• Pon la regla en el punto que pueda hacerla cumplir para cada productor relevante. Los adaptadores de entrada establecen la confianza del llamador, analizan entradas, invocan a ese dueño y traducen el resultado. Las comprobaciones tempranas útiles mejoran la retroalimentación; las comprobaciones autoritarias protegen el efecto real.
• Modela explícitamente quién posee los datos compartidos. Un valor padre o de ámbito faltante no es automáticamente autoridad global. Aplica la política real del actor a lecturas, serialización y efectos, no solo a controles visibles.
• Separa las relaciones actuales, los hechos de ocurrencia inmutable y las proyecciones. Almacena el historial o la instantánea que la funcionalidad realmente necesita. Las relaciones presentes no pueden reconstruir hechos pasados faltantes; marca honestamente el historial heredado incognoscible.
• Dale a un reintento su identidad de operación. Dos cargas útiles idénticas pueden ser intenciones separadas. Define el ámbito de la clave, la reutilización incorrecta, la retención y la reproducción bajo la autoridad actual cuando la corrección del reintento importe.
• Dale a las reglas y representaciones derivadas una única definición mantenida donde los consumidores deban coincidir. Preserva las diferencias intencionales entre audiencias, cohortes, unidades y significados temporales. Mantén la duplicación barata de presentación local cuando compartir crearía una dependencia artificial.
• Los diseños multiescritura o fuera de línea especificados explícitamente son válidos. Nombra la semántica de conflicto, la coordinación y el comportamiento de partición en lugar de asumir que se puede imponer siempre un único escritor físico.

Un límite gana su existencia al ocultar una decisión y eliminar conocimiento de los llamadores. Verifica esto directamente: después del cambio, ¿qué llamador ya no conoce la regla, el diseño de almacenamiento o la secuenciación? Un envoltorio que deja a cada llamador coordinando los mismos pasos de negocio no ha movido la propiedad.

Posee el resultado completo

Traza una intención a través de sus efectos importantes. Indica qué debe mantenerse junto, el punto de finalización autoritario y qué recibe el usuario si la ejecución se detiene antes o después de ese punto.

Enumera cada publicación observable, incluyendo cachés y retrollamadas en segundo plano. Para trabajo asíncrono, identifica la operación, identidad, versión y tiempo de vida al que pertenece un resultado, y verifica su aplicabilidad en cada límite de publicación relevante. Una verificación tardía de vista no puede proteger una escritura anterior en caché o almacén. Distingue cancelar un consumidor de deshacer un efecto de negocio ya confirmado.

Usa una primitiva atómica real para invariantes que requieran indivisibilidad dentro de una autoridad. Donde escritores concurrentes puedan invalidar una lectura previa, aplica el ámbito, estado y versión relevantes en el efecto o serialización equivalente. Adecúa el mecanismo a una intercalación alcanzable; una transformación pura de un solo hilo no necesita maquinaria de concurrencia tipo base de datos.

En límites de red, proceso, archivo o asíncronos, lee Comprobaciones de límite. Selecciona la rama relevante: efectos duraderos, tiempo de vida del recurso, trabajo en tiempo real o estado/historial. Una transacción local no hace atómico un efecto externo; un resultado desconocido no es necesariamente un fallo. Define la recuperación y los resultados pendientes/parciales veraces antes de añadir reintentos.

Para APIs reutilizables, haz explícitas las entradas, salidas, rechazos, propiedad y responsabilidades de limpieza. Preserva las distinciones significativas de error/flujo de control. Coloca la diagnosis donde un fallo pueda explicarse sin exponer datos protegidos; un registro no es un mecanismo de recuperación ni una base de datos de autorización/historial.

Elige una estructura proporcional

Prefiere el módulo coherente existente y los mecanismos de plataforma soportados. En una aplicación nueva y pequeña, unas pocas funciones o módulos bien acotados pueden ser suficientes. Separa el despliegue o introduce infraestructura cuando un requisito concreto necesite escalado independiente, aislamiento de fallos, restricciones de tiempo de ejecución u propiedad organizativa. Respeta una plataforma explícitamente elegida mientras explicas una compensación importante.

Evalúa el cambio más pequeño junto a una alternativa plausible. Explica la diferencia importante en corrección, costo operativo/de recursos y reversibilidad. Mantén cada decisión de diseño en un solo hogar; extrae independientemente solo costuras estables y útiles. Las carpetas físicas, paquetes y servicios siguen límites probados en lugar de proporcionar la prueba.

Preserva el invariante completo a través de un cambio de ubicación. La migración y el despliegue deben tener en cuenta los datos existentes, escritores antiguos/nuevos, consumidores públicos y compatibilidad de reversión. La eliminación de una columna, API o recurso requiere evidencia de que sus obligaciones y consumidores han terminado.

Intenta refutarlo

Elige un segmento vertical delgado que ejercite el límite en disputa. Usa el almacenamiento real, archivo, protocolo o costura de recurso relevante para la afirmación; aísla solo las dependencias externas genuinas. Para un diseño temprano sin implementación, especifica el experimento discriminante y deja su resultado desconocido.

Desafía el invariante con los fallos relevantes: autoridad incorrecta, estado obsoleto, trabajo repetido o reordenado, un bloqueo en el límite de finalización, cancelación, historial faltante/ambiguo y el límite real de carga o tiempo. Usa señuelos explícitos e intercalaciones o relojes controlados cuando distingan la regla. Una prueba debería fallar cuando esa regla se elimina, no solo contar llamadas simuladas o reconocer nombres elegidos.

Verifica seguridad y progreso: cómo una operación válida se completa eventualmente o da un rechazo honesto; cómo se recupera el trabajo pendiente; cómo la memoria, colas, conexiones y latencia permanen acotados. Selecciona estas comprobaciones del ámbito operativo en lugar de ensayar cada fallo teórico.

Observa el flujo montado/usuario o de librería pública cuando afirmas que funciona. Las aserciones unitarias, diagramas, reintentos verdes, estimaciones de referencia y accesorios sintéticos establecen solo su propio límite probado. Separa los resultados medidos, hallazgos de fuente, suposiciones, decisiones faltantes y pruebas no ejecutadas.

Entrega una decisión revisable

Escala la salida según la decisión. Para un diseño sustancial, proporciona:

1. El flujo concreto, las restricciones y las incógnitas importantes.
2. Los invariantes, las autoridades nombradas y los productores/consumidores afectados.
3. Estado/historial, confianza, finalización y límites de fallo, con contratos suficientes para rastrear un éxito y un fallo.
4. La pequeña estructura elegida, una alternativa relevante y por qué la compensación es adecuada.
5. Un primer segmento con comprobaciones observables de aceptación, recuperación y evolución/despliegue.
6. Lo que está listo, lo que necesita una decisión de producto o una prueba, y lo que realmente se verificó.

Usa un diagrama pequeño solo cuando haga más claro un límite. Omite secciones de plantilla vacías para una corrección local. Preserva el ámbito del usuario: una solicitud de diseño/revisión produce una decisión, no permiso para implementar, migrar, desplegar, publicar o alterar datos en vivo.

Al adoptar o evaluar esta habilidad, consulta Protocolo de evaluación. La base principal se enumera en Fundamentos; informa el razonamiento en lugar de validar un diseño individual.