Vertical slices: de PostgreSQL al smoke de producción

23 de agosto de 2026

Durante años aprendí a construir software por capas horizontales: primero el esquema, luego el dominio, después la API, más tarde la UI. Ese enfoque organiza equipos grandes, pero retrasa la evidencia de que algo funciona. Un vertical slice atraviesa todas las capas necesarias para entregar una capacidad concreta —desde PostgreSQL hasta el smoke de producción— en lugar de completar una capa entera para todo el producto.

El recorrido completo

El diagrama de este artículo muestra una secuencia representativa:

PostgreSQL / migración
  → Domain
  → FastAPI
  → tests
  → fixtures / scenarios
  → demo / seed
  → CLI
  → Skill / Runbook
  → UI
  → deploy
  → smoke

No todo proyecto necesita las once paradas en cada feature, pero la pregunta permanece: ¿qué falta para que esta capacidad exista de verdad?

Una feature no termina en la pantalla

Una pantalla puede mostrar datos mock, un endpoint puede devolver fixtures estáticos y un CLI puede existir solo en documentación. Ninguno de esos estados demuestra que la capacidad opera en el mundo real.

Un slice terminado implica:

• Ejecutarse: la operación mutante o de consulta funciona contra el almacenamiento real o un sustituto fiel.
• Demostrarse: demo o seed reproducible para revisores y agentes.
• Operarse: CLI, runbook o skill documentan cómo usarla fuera del IDE.
• Verificarse: smoke en staging o producción confirma que el camino desplegado sigue vivo.

Por qué el orden importa menos que la completitud

Algunos equipos prefieren comenzar por la API; otros por una migración. Lo relevante es que el slice conecte las piezas antes de abrir otro frente. Una migración sin dominio es deuda; un dominio sin test es especulación; una UI sin CLI dificulta operación agéntica.

En este archivo, API-first y CLI-first describe la mitad operativa del slice: contrato API estable e invocación determinista antes de razonamiento agéntico.

Fixtures y escenarios

Los fixtures no son datos de relleno: son escenarios que hacen falsable el comportamiento. Un escenario de factura duplicada, un usuario sin permiso, un lote vacío —cada uno debe poder ejecutarse contra el mismo stack que producción, acotado.

Los tests unitarios aíslan; los escenarios integran. Ambos pertenecen al slice, con roles distintos.

Deploy y smoke: la prueba que no se negocia

El deploy materializa el artefacto; el smoke pregunta si el artefacto sirve. Un smoke mínimo —health check, operación de lectura, mutación acotada en entorno controlado— cierra el slice.

Sin smoke, «está desplegado» significa solo «está en un servidor». La diferencia importa especialmente cuando agentes automatizan despliegues: el éxito del pipeline no sustituye verificación de capacidad.

Límites

Vertical slice no significa «sin arquitectura». Significa posponer abstracciones hasta que una capacidad concreta las justifique. Tampoco elimina refactors posteriores: un slice bien acotado hace esos refactors más seguros porque hay tests y smoke que detectan regresiones.

No todo el producto debe ser un solo slice. Pero ninguna feature debería declararse terminada sin haber atravesado el camino vertical mínimo que su riesgo exige.