System Design
Explica cómo revisar un diseño con escenarios, walkthroughs, expertos, evidencia y criterios explícitos para detectar contradicciones, vacíos y riesgos antes de construir.
Un diseño no se aprueba porque el diagrama se vea ordenado. Se aprueba cuando existe evidencia suficiente de que resuelve la necesidad, conserva sus reglas, puede operarse y sus riesgos residuales son aceptables.
Revisar un diseño significa someterlo a preguntas, escenarios y evidencia antes de que las decisiones costosas queden incrustadas en código, datos y operación.
La revisión cumple dos propósitos relacionados:
verificación
→ ¿el diseño implementa correctamente los requisitos y reglas definidos?
validación
→ ¿esos requisitos y este diseño resuelven realmente la necesidad?Un diseño puede estar perfectamente documentado y aun así resolver el problema equivocado.
Una buena revisión no termina en “aprobado” o “no aprobado”. Debe dejar:
No siempre se necesitan todos los diagramas, pero sí contexto suficiente para revisar.
problema y objetivos
+ alcance y exclusiones
+ requisitos y reglas críticas
+ escenarios principales y de fallo
+ modelo de dominio y datos relevantes
+ contratos e integraciones
+ atributos de calidad
+ riesgos y decisiones abiertasPresentar solo un diagrama de componentes obliga a los revisores a imaginar las necesidades que supuestamente soporta.
Una revisión genérica produce comentarios genéricos. Empieza declarando qué se necesita decidir.
Ejemplos:
No todas las personas revisan lo mismo.
Excluir una perspectiva no elimina sus riesgos.
La revisión debe usar historias concretas, no solo inspección estática.
estado inicial
→ actor realiza acción
→ sistema toma decisiones
→ dependencias responden o fallan
→ estado final
→ evidencia observableRecorre como mínimo:
Busca contradicciones entre documentos.
Ejemplo:
Caso de uso: permite cancelar en preparing
State diagram: no existe esa transición
API: expone POST /cancel sin condición
Regla: solo manager puede cancelar
Pruebas: solo cubren pendingCada artefacto aislado puede parecer correcto; juntos revelan el hueco.
Pregunta cómo se manifiestan las propiedades no funcionales en el diseño.
Clasifica para evitar que todo parezca igual de urgente.
Bloqueante
→ invalida objetivo, integridad, seguridad o viabilidad
Importante
→ riesgo significativo que necesita plan
Mejora
→ aumenta claridad o sostenibilidad
Pregunta
→ información insuficiente para decidirUna revisión se cierra cuando los bloqueantes están resueltos, los riesgos importantes tienen owner y la evidencia pendiente está explícita. No se cierra porque terminó la reunión.
El equipo recorre un escenario paso a paso y explica decisiones, estados, datos y fallos.
Revisión estructurada de drivers, alternativas, contratos, riesgos y consecuencias.
Reduce una incertidumbre concreta mediante evidencia.
Recorre activos, actores, límites y abusos posibles.
Verifica compatibilidad entre consumidor y proveedor.
Útil cuando existen estados, concurrencia o reglas complejas.
Ejecuta restore, failover, rollback, drenado o recuperación en un entorno controlado.
Supuesto diseño:
cancelled.Preguntas de revisión:
La revisión puede concluir que cancelled no debe establecerse hasta completar compensaciones o que se necesita un estado cancellation_pending.
El objetivo no es predecir cada evolución futura. El diseño es suficiente cuando:
El exceso de detalle también genera coste y envejece rápido.
Oculta los fallos que más influyen en estructura y operación.
La factibilidad técnica no valida reglas, soporte ni experiencia operativa.
Varias personas pueden compartir el mismo supuesto incorrecto. Busca evidencia.
Una lista ayuda a recordar preguntas, pero no reemplaza análisis de riesgos.
El hallazgo desaparece aunque quede escrito.
El diseño es una hipótesis compartida, no la identidad de quien lo propuso.
Diseño y estrategia de pruebas convierte requisitos, riesgos y decisiones en evidencia repetible.