System Design
Alcance, límites y contexto
Explica cómo definir responsabilidades, capacidades incluidas, exclusiones, fuentes de verdad, dependencias y contexto para evitar scope creep.
- Última actualización
- Actualizada
- Nivel
- Fundamentos
System Design
Explica cómo definir responsabilidades, capacidades incluidas, exclusiones, fuentes de verdad, dependencias y contexto para evitar scope creep.
El alcance no es una lista decorativa de funcionalidades. Es un acuerdo verificable sobre qué problema asume el sistema, dónde termina su responsabilidad y qué condiciones externas debe tratar como dependencias.
Definir alcance significa transformar una visión amplia en una frontera de responsabilidad concreta. Un sistema puede participar en un proceso sin ser dueño de todo el proceso.
problema amplio
→ identificar resultado prioritario
→ definir actores y capacidades incluidas
→ declarar exclusiones
→ ubicar sistemas externos y trabajo humano
→ validar que el límite sigue resolviendo algo útilSin esta frontera, cada necesidad adyacente termina convertida en requisito y el sistema crece sin una definición clara de terminado.
Supón que una tienda dice: “necesitamos mejorar los domicilios”. Esa frase puede involucrar:
Intentar resolver todo en una primera versión diluye el objetivo, aumenta dependencias y retrasa la validación. Definir alcance permite elegir qué parte del problema se abordará ahora y qué quedará fuera de forma consciente.
Sistema de pedidos
├─ es responsable de
│ ├─ registrar pedido
│ ├─ validar información mínima
│ ├─ mantener estado
│ └─ coordinar asignación
├─ colabora con
│ ├─ pasarela de pago
│ ├─ inventario
│ └─ proveedor de notificaciones
└─ no es responsable de
├─ liquidar nómina
├─ optimizar tráfico urbano
└─ llevar contabilidad generalLa frontera debe explicar quién decide, quién conserva el dato autoritativo y qué ocurre cuando una dependencia no responde.
Incluye capacidades que forman parte del compromiso actual. Deben describirse como resultados o responsabilidades, no como nombres de pantallas.
In scope
- Crear pedidos con productos, cantidades y dirección.
- Validar que la sucursal pueda atenderlos.
- Asignar un repartidor disponible.
- Registrar y exponer cambios de estado.Declara capacidades deliberadamente excluidas. No significa “nunca”; significa que no forman parte del diseño o entrega actual.
Out of scope en esta versión
- Optimización automática de rutas.
- Pago de nómina.
- Marketplace entre negocios.
- Contabilidad general.Una exclusión útil incluye el motivo cuando podría generar discusión: alto coste, hipótesis aún no validada, dependencia futura o ausencia de valor inmediato.
El contexto muestra qué rodea al sistema: personas, sistemas externos, canales, reguladores y procesos manuales.
flowchart LR
Customer["Cliente"] -->|"crea y consulta pedidos"| Orders["Sistema de pedidos"]
Ops["Operaciones"] -->|"prepara y asigna"| Orders
Orders -->|"consulta disponibilidad"| Inventory["Sistema de inventario"]
Orders -->|"solicita cobro"| Payment["Pasarela de pago"]
Orders -->|"envía mensajes"| Notification["Proveedor de notificaciones"]Este diagrama responde quién interactúa y con qué propósito. No intenta mostrar bases de datos, clases ni algoritmos internos.
Pregunta qué cambio debe observarse cuando el sistema funcione. “Tener una app” no es un resultado. “Reducir pedidos perdidos y conocer su estado” sí lo es.
Describe el recorrido más importante desde el disparador hasta el resultado:
cliente solicita pedido
→ negocio confirma
→ prepara
→ asigna entrega
→ cliente recibePuede registrar la preparación sin ejecutarla físicamente. Puede solicitar un pago sin convertirse en procesador financiero.
Para cada dato importante:
Ejemplo: inventario puede ser fuente autoritativa de stock; pedidos conserva un snapshot de lo vendido.
Las exclusiones evitan que expectativas no discutidas reaparezcan tarde.
Recorre happy path, errores y operaciones. Si el alcance no dice quién resuelve una cancelación, una devolución o una pasarela caída, todavía es ambiguo.
No son exactamente lo mismo.
Separa dominios o responsabilidades empresariales: ventas, inventario, logística y contabilidad.
Define qué software se está diseñando y con cuáles sistemas colabora.
Indica qué subconjunto se construirá en una versión concreta.
Un sistema puede tener una visión amplia mientras una primera entrega solo cubre creación y seguimiento básico de pedidos.
Un MVP es la versión mínima que permite probar una hipótesis o producir valor. No es “todo mal hecho pero rápido”.
Ejemplo:
Hipótesis
→ centralizar pedidos reduce pérdidas de información
MVP
→ registro, validación mínima, estados y vista operativa
No necesario para validar
→ recomendación automática de rutasCalidad, integridad y seguridad necesarias no se eliminan por llamar MVP a la entrega.
Problema: pedidos dispersos entre WhatsApp, llamadas y hojas de cálculo.
Alcance inicial razonable:
Fuera del alcance inicial:
Decisión importante: inventario y pedidos deben coordinarse, pero no todo el módulo contable tiene que entrar en la misma versión.
Una solicitud “pequeña” puede afectar mucho más que UI:
“Añadamos pedidos programados”
→ nuevas fechas y zonas horarias
→ reglas de capacidad
→ estados futuros
→ cancelación
→ jobs
→ notificaciones
→ pruebas y operaciónAntes de aceptar un cambio, registra:
El alcance debe aclarar si el sistema reintenta, deja operación pendiente, ofrece alternativa manual o rechaza.
Automatizar una parte no elimina automáticamente pasos humanos. Documenta handoffs y responsabilidades.
Surgen conflictos y reconciliaciones. Decide autoridad y dirección de sincronización.
Puede ampliar el alcance obligatorio aunque no aporte una funcionalidad visible.
Una entrega puede ser técnicamente pequeña pero incapaz de completar un resultado útil. El corte debe ser vertical.
Oculta responsabilidades, datos y resultados. Corrígelo expresando capacidades y flujos.
Una exclusión puede dejar un hueco operativo. Explica cómo se resuelve temporalmente.
Produce un sistema sin foco. Separa dominios y entregas.
Toda dependencia introduce latencia, errores, límites y cambios contractuales.
Decidir microservicios no define qué problema se resuelve.
Amplía cuando un resultado no puede completarse o una obligación crítica quedó fuera. Reduce cuando una capacidad no valida la hipótesis, introduce dependencias desproporcionadas o puede conservarse manualmente temporalmente.
Glosario y lenguaje del dominio define las palabras que permitirán describir requisitos, reglas y modelos sin ambigüedad.