BlackMesa Labs

Nuestra capa de dominio solo contiene excepciones. A propósito.

2026-10-04T00:00:00+00:00

Los artículos sobre arquitectura hexagonal muestran casi siempre el mismo esquema: un círculo en el centro, puertos alrededor, adaptadores fuera y una flecha que apunta hacia dentro. Ninguno enseña nunca qué contiene la carpeta Domain/ seis meses después.

Aquí está la nuestra. Nueve contextos y, en total, doce archivos de dominio: nueve excepciones, dos enumeraciones, un rol. Cero interfaces. Cero agregados. Cero objetos de valor. Llamar a eso capa de negocio sería mentir, y de eso trata exactamente este artículo.

Lo que conservamos: la C de CQRS, no la Q

La configuración del bus declara tres canales con una semántica explícita:

default_bus: command.bus
buses:
    command.bus:            # un comando muta el estado, exactamente un manejador
        default_middleware: { enabled: true, allow_no_handlers: false }
    query.bus:              # una consulta devuelve un valor, un único manejador
        default_middleware: { enabled: true, allow_no_handlers: false }
    event.bus:              # un evento de dominio: 0..n suscriptores
        default_middleware: { enabled: true, allow_no_handlers: true }

El recuento real a día de hoy: veintinueve manejadores de comando, uno solo de consulta. El bus de consultas existe, está configurado y está casi vacío.

No es deuda de migración, es una conclusión. Un comando merece su ceremonia porque aporta tres cosas que antes no teníamos: un nombre de intención (ChangeCompanySubscriptionPlan no es setSubscriptionPlan), la garantía de que existe exactamente un sitio que lo ejecuta — allow_no_handlers: false falla al arrancar, no en producción — y una frontera de transacción evidente, la del manejador.

Una lectura no aporta nada de eso. Su forma la dicta la pantalla que la muestra: esta página necesita estas siete columnas, unidas así, ordenadas de esta manera. Pasar eso por un bus no añade ninguna regla, añade una capa y traslada el SQL de un archivo a otro. Así que leemos a través de los repositorios de Doctrine, directamente, y sin pedir perdón por ello.

Un detalle que importa más de lo que parece: default_bus: command.bus. Un dispatch() sin más es un comando. El valor por defecto es el canal que muta el estado, es decir, el único que nunca quieres ver saliendo por el canal equivocado.

Lo que rechazamos: la inversión de dependencias

Es el corazón del hexágono en la literatura: el dominio declara interfaces, la infraestructura las implementa, la flecha de dependencia apunta hacia dentro. No lo hicimos. Aquí va un manejador entero, sin cortes:

#[AsMessageHandler(bus: 'command.bus')]
final readonly class ChangeCompanySubscriptionPlanHandler
{
    public function __construct(
        private EntityManagerInterface $entityManager,
        private LoggerInterface $logger,
    ) {}

    public function __invoke(ChangeCompanySubscriptionPlanCommand $command): void
    {
        $company = $this->entityManager->find(Company::class, Ulid::fromString($command->companyId));
        if (!$company instanceof Company) {
            throw CompanyNotFoundException::withId($command->companyId);
        }
        // …
    }
}

EntityManagerInterface como dependencia directa. De treinta y ocho manejadores, veinticuatro dependen de él. La entidad Company viene de App\Entity, compartida por todos los contextos. No hay repositorio abstracto, ni puerto, ni modelo de dominio distinto de la tabla.

Dos observaciones sobre ese ejemplo, porque dicen más que el esquema.

Primera: el comando transporta string $companyId, no un objeto de valor CompanyId. No es pereza: el mensaje tiene que poder serializarse para el transporte asíncrono. La frontera del bus impone la forma del mensaje — infraestructura dictando la firma de lo que llamamos dominio, desde la primera línea.

Segunda: Ulid::fromString(...). El identificador del dominio existe en dos formas según se transporte o se consulte con él, y esa conversión es una restricción del almacenamiento, no del negocio.

Lo que la frontera compra de todos modos

Una cosa, exactamente una, y vale su precio: el acoplamiento entre contextos se volvió visible en la lista de importaciones.

El manejador anterior vive en App\Billing. Importa App\Company\Domain\Exception\CompanyNotFoundException. Esa sola importación dice que la facturación depende del contexto Empresa, y lo dice en la cabecera del archivo, en una línea, sin ningún diagrama que mantener al día. El grafo de dependencias entre contextos se obtiene con un grep sobre los use.

Es modesto. Comparado con una base donde todo vive en App\Service, es la diferencia entre «suponemos que está acoplado» y «aquí está exactamente dónde». Ese beneficio es lo que compramos, y nada más.

Los cinco puntos por donde cruza la infraestructura

Esto es lo que ningún esquema enseña: los sitios donde Doctrine decide la forma de una operación de negocio. Son fugas reales, todas presentes hoy en el código.

1. La regla de negocio escrita en dos dialectos. Nuestra política para mantener a las empresas internas fuera de las cifras comerciales cabe en un predicado. Existe en dos versiones, porque algunos caminos de lectura son SQL nativo por rendimiento y otros son DQL:

public static function sql(string $alias = 'c'): string  // consultas nativas
{ return ($alias !== '' ? $alias.'.' : '').'excluded_from_stats = false'; }

public static function dql(string $alias = 'c'): string  // consultas del ORM
{ return $alias.'.excludedFromStats = false'; }

Una regla, dos escrituras, por culpa del lenguaje de consulta. La divergencia es de un carácter — excluded_from_stats frente a excludedFromStats — así que resulta invisible en una lectura rápida, y no hay ninguna prueba que fallara si una de las dos se desviara.

2. El filtro ambiental. El filtro de borrado lógico de Doctrine es estado global mutable. Una consulta que busca un identificador único no encuentra nada mientras el índice único sí lo sigue reteniendo. La salida es desactivar el filtro y volver a ponerlo:

$filters = $this->em->getFilters();
$wasEnabled = $filters->isEnabled('softdeleteable');
if ($wasEnabled) { $filters->disable('softdeleteable'); }
$existing = $repo->findOneBy(['slug' => $slug]);
if ($wasEnabled) { $filters->enable('softdeleteable'); }

Una «consulta de negocio» cuyo resultado depende de un estado ambiental no es una función. No es un defecto de Doctrine — el filtro hace exactamente lo que le pedimos — pero impide razonar sobre el código de aplicación sin saber en qué modo se ejecuta.

3. El orden de escritura dentro de la unidad de trabajo. Reemplazar las traducciones de un contenido parece una sola operación: quitar las antiguas, añadir las nuevas, guardar. Dentro de un único flush(), Doctrine ejecuta los INSERT antes que los DELETE de huérfanos, y la restricción de unicidad sobre (feedback_id, locale) revienta. Hay que partir la operación en dos guardados sucesivos.

Dicho de otro modo: la forma de la operación aplicativa no la fija el negocio, sino la planificación interna del ORM. Ningún puerto habría protegido de eso, porque la restricción no vive ni en el dominio ni en el adaptador: vive en el orden de ejecución que los une.

4. El alias de unión que trunca en silencio. Filtrar sobre una asociación ya unida con fetch restringe además la colección hidratada: crees que filtras filas y estás amputando el objeto devuelto. El filtrado necesita su propia segunda unión:

$qb->innerJoin('f.industries', 'i_filter')      // alias distinto del de fetch
   ->andWhere('i_filter.id IN (:industries)');

El fallo es invisible: la consulta devuelve las entidades correctas, con colecciones incompletas. Es semántica de infraestructura, en mitad de lo que parece una regla de búsqueda.

5. El tipo del identificador. Los identificadores viajan como ULID, se comparan en RFC 4122 dentro de las consultas, y olvidar la conversión produce un resultado vacío en lugar de un error. Un puerto habría desplazado la conversión; no la habría eliminado.

La regla de migración

Queda la pregunta que mata las reescrituras: ¿qué hacemos con el código existente, escrito como servicios clásicos de Symfony?

Nada, mientras nadie lo toque. La política está escrita: CQRS para las escrituras y lecturas nuevas; el código existente migra solo bajo demanda. Nunca una reescritura masiva en nombre de la homogeneidad.

Porque la homogeneidad no es un resultado de negocio. Reescribir un servicio que funciona para que se parezca a sus vecinos produce riesgo sin producir valor, y es exactamente el tipo de trabajo que se justifica solo, indefinidamente, porque su criterio de parada es estético.

Esto no es DDD purista, es time to market

Hay que nombrar la razón de verdad, porque todo lo anterior se lee de otra manera una vez puesta sobre la mesa.

Ya hemos escrito aquí que la funcionalidad más barata es la que no se construye. Un puerto es una funcionalidad. Un agregado también, un objeto de valor también, una capa anticorrupción también. Cada uno cuesta escribirlo, cuesta leerlo a quien llegue después, y cuesta mantenerlo mientras el código siga vivo. Una abstracción no es gratis por ser inmaterial.

La pregunta útil no es, por tanto, «¿esto es DDD correcto?». Es: ¿qué compra esta abstracción hoy y qué se limita a aplazar? Un repositorio detrás de una interfaz compra la posibilidad de cambiar de almacenamiento — no vamos a dejar PostgreSQL. Compra también pruebas sin base de datos, y eso sí es un beneficio real: es el único argumento que quizá nos haga pagar la factura algún día.

Lo que hicimos en su lugar cabe en una frase: entregar, y conservar solo las fronteras que se pagan solas. El bus de comandos cuesta tres archivos y sirve el mismo día. Los puertos cuestan una capa entera y quizá sirvan, más adelante, a un equipo que todavía no existe.

El riesgo de esta postura es conocido, y escribirlo forma parte del precio: se parece muchísimo a la pereza. La diferencia está en un solo detalle — sabemos nombrar lo que no construimos, y por qué.

Y lo asumimos. Estas decisiones son nuestras, no accidentes que descubriríamos al releer. Las corregimos cuando podemos y cuando tenemos tiempo: el día en que una molestia se vuelve real y medible, no el día en que un artículo de arquitectura nos explica que son incorrectas. Una deuda escrita, fechada y argumentada no es una deuda negada: es la única que uno es capaz de devolver en el momento adecuado.

Lo que dio de sí

Nueve contextos con nombre, cuyo acoplamiento mutuo se lee en las importaciones y no en un diagrama caducado.
Veintinueve comandos, cada uno con un nombre de intención, un manejador único garantizado en el arranque y una frontera de transacción evidente.
Un único manejador de consultas, asumido: las lecturas pasan por los repositorios.
Doce archivos de dominio — nueve excepciones, dos enumeraciones, un rol — es decir, ninguna regla de negocio realmente aislada de Doctrine.
Cero reescrituras del código clásico existente, que sigue funcionando al lado.

Buenas prácticas

Tratar cada abstracción como una funcionalidad: tiene que decir qué compra hoy, no qué permitiría algún día.
Adoptar las piezas por separado. El bus de comandos aporta algo sin el resto; los puertos, los agregados y los objetos de valor son compras distintas, cada una con su factura.
Elegir el valor por defecto más estricto: el bus por defecto es el que muta el estado, y la ausencia de manejador hace fallar el arranque en lugar de la producción.
Usar los espacios de nombres como detector de acoplamiento y no como barrera: no protegen de nada, hacen visible.
Escribir la regla de migración con su criterio de parada. Sin él, «homogeneizar la arquitectura» es un trabajo infinito.
Mirar qué contiene realmente Domain/ antes de decir que se hace DDD. El recuento es instructivo.

Puntos de vigilancia

La carpeta no es la frontera. Crear Domain/, Application/, Infrastructure/ da una sensación reconfortante de avance medible, y medir una arquitectura por su número de carpetas es la forma más segura de no obtener ninguna de las garantías que sugieren.
Veinticuatro de treinta y ocho manejadores dependen del EntityManager: ninguno puede probarse con un repositorio en memoria. La batería de pruebas necesita una base de datos real. Es un coste, está asumido, no es gratis.
Las entidades compartidas de Doctrine son el acoplamiento real, y es invisible en el árbol de carpetas. El día en que dos contextos quieran que la misma tabla diverja, ese será el muro, no la ausencia de puertos.
Una regla de negocio duplicada en dos dialectos de consulta acabará divergiendo, y hoy nada lo detectaría. Es la deuda más concreta de todo lo anterior.

Éramos nuestro propio mejor cliente. Era un fallo.

2026-09-30T00:00:00+00:00

Todo el mundo recomienda usar el propio producto. Nadie advierte del efecto secundario: en cuanto tu empresa tiene una cuenta, entra en tus cifras. No en una nota al pie, sino en la facturación, en la tasa de conversión, en la lista de clientes a los que hay que llamar.

Nuestro caso: BlackMesa publica casos reales en Show me the REX. La cuenta es real, el plan es real, los artículos se leen. Lo que no es real son los ingresos: no nos facturamos a nosotros mismos. Resultado: un cliente de cero euros figuraba en el MRR, inflaba el reparto por planes y ocupaba una casilla del embudo de conversión sin haber convertido jamás nada.

La corrección evidente — «excluimos nuestra empresa» — es falsa. Da por supuesto que el problema es la empresa. El problema está en otro sitio.

No es «a quién excluir», es «qué responde esta cifra»

El reflejo es buscar una lista de entidades que apartar. La pregunta correcta se plantea métrica a métrica: ¿de qué pregunta es respuesta esta cifra?

Un contador de visualizaciones responde a «cuánta gente ha leído este texto». La respuesta es la misma venga el lector de nuestras oficinas o de cualquier otro sitio: la página se sirvió, se leyó, el contenido existe. Excluir nuestras visualizaciones volvería falsa esa cifra.

La facturación mensual responde a «cuánto nos pagan nuestros clientes». Nuestra propia empresa no es un cliente. Su presencia vuelve falsa esa cifra.

Ambas métricas miran la misma base de datos, a veces la misma fila, y necesitan reglas opuestas. No es una excepción que gestionar, es la regla: la unidad de exclusión no es el dato, es la pregunta formulada.

El caso que zanja: una visualización que cuenta y no cuenta

El mejor ejemplo es también el más incómodo, porque descarta cualquier atajo de implementación.

En la plataforma, la visualización de un caso alimenta dos cosas distintas. Por un lado la audiencia: el contador que aparece en el artículo, el acumulado del panel, la curva de tráfico. Por otro, una señal comercial: «qué empresas han consultado tus casos», que sirve para identificar contactos con los que retomar el hilo.

Mismo evento, mismo registro. En el primer grupo, una lectura hecha desde nuestras oficinas cuenta: alguien ha leído de verdad. En el segundo no debe contar de ninguna manera: no somos un cliente potencial al que llamar, y un lector interno dentro de una lista de leads es una acción comercial disparada para nada.

No existe, por tanto, un filtro global que se ponga una sola vez en la entrada. Cada consulta tiene que saber a qué familia pertenece.

Una marca en la base de datos, no una constante en el código

Primera versión, la más rápida: una lista de nombres de empresa escrita en el código. Duró una hora. Una constante obliga a desplegar para reclasificar una empresa y, sobre todo, miente sobre la naturaleza de la información: «esta empresa no es un cliente» es un dato de negocio, cambia, se decide, y tiene que estar a la vista de quien administra las cuentas.

Así que se convirtió en una casilla en la ficha de empresa, con su texto de ayuda explícito, porque una opción cuyo alcance nadie entiende acaba marcada al azar:

Nuestras propias empresas publican y siguen visibles en el sitio público, pero no cuentan en ningún dato comercial ni de marketing: MRR, planes, embudo, upsell/abandono, leads, resúmenes. Las visualizaciones y las visitas sí se siguen contando.

La lista de nombres no desapareció: sirve de arranque, para que un entorno recién instalado no empiece nunca con cifras contaminadas. Pero ya no decide nada.

El predicado en sí vive en una única clase pequeña, en dos versiones: una para las consultas del ORM y otra para el SQL en crudo. Parece anecdótico; es lo que hace la regla auditable. Encontrar los sitios que la aplican se convirtió en una búsqueda de texto, y contrastarla con la lista de cifras comerciales se hace a ojo en un minuto.

Verificar en lugar de releer

Releer el propio código de exclusión no demuestra nada: uno relee lo que cree haber escrito. La única verificación que vale consiste en cambiar la casilla y comparar los paneles antes y después, cifra por cifra.

Una treintena de valores se movieron. Siete se quedaron rigurosamente idénticos, y ese era el resultado esperado: son los contadores de audiencia y los volúmenes de contenido publicado. Una cifra que se mueve cuando no debía es un fallo; una cifra que no se mueve cuando debía es un olvido. Sin ese paso no habríamos distinguido ninguno de los dos.

El resultado final: una marca, una clase de política, treinta y cuatro predicados repartidos en ocho archivos — MRR, planes, embudo, upsell, riesgo de abandono, seguimientos, inteligencia comercial, resúmenes mensuales, caducidad de cupones, nurturing.

Este último merece una mención. Sin la exclusión, nuestra propia empresa entraba en la secuencia automática de reactivación. Nos habríamos enviado nuestros propios correos de recuperación.

Lo que dio de sí

Un MRR sin ningún cliente de cero euros dentro, y una tasa de conversión que ya no cuenta nuestro propio registro en el denominador.
Una treintena de valores corregidos en los paneles comerciales, siete intencionadamente sin cambios.
Cero cambios en la parte pública: los casos siguen publicados, visibles, filtrables, y sus visualizaciones se siguen contando.
Una regla escrita en un solo sitio, con su motivo, en lugar de un AND copiado de consulta en consulta.
Una casilla que permite reclasificar una empresa sin desplegar.

Buenas prácticas

Clasificar cada métrica antes de programar el filtro: medida de audiencia o señal comercial. La respuesta determina la regla, y no es la misma para dos cifras sacadas de la misma tabla.
Poner la pertenencia en la base de datos, no en una constante: es un dato de negocio, cambia y se decide.
Concentrar el predicado en una sola clase aunque quepa en una línea: lo importante no es reutilizarlo, es poder encontrar todas las llamadas.
Verificar cambiando la casilla: comparar las cifras antes y después es la única forma de distinguir un olvido de una decisión.
Escribir el alcance en la interfaz de administración, justo donde se marca la casilla.

Puntos de vigilancia

Nada impide que la próxima consulta olvide el predicado. La regla se sostiene con la revisión de código, no con una prueba automática, y hoy esa es la debilidad principal del montaje.
Una exclusión demasiado amplia es tan falsa como la ausencia de exclusión: quitar nuestras visualizaciones del contador de audiencia habría producido una mentira en el otro sentido.
El día en que una empresa interna se convierta en cliente de pago de verdad, habrá que desmarcar la casilla, y nadie lo recordará. Esa decisión es humana y necesita un momento fijado para revisarla.
Decir públicamente que tus estadísticas excluyen tus propios datos no cuesta nada, y es mejor que descubrirlo en boca de otro.

La funcionalidad más barata es la que no se construye

2026-09-27T00:00:00+00:00

La sobriedad digital casi siempre se plantea como un problema de optimización: imágenes más ligeras, mejor caché, una región más limpia. Todo es cierto, y todo es marginal. El desperdicio real está en otra parte, y nadie lo mide: el código escrito para nada. Una migración que rehacer, una herramienta comprada y abandonada, una funcionalidad entregada que nadie abre. Queda la pregunta que nunca habíamos formulado: ¿cómo se decide no construir algo?

El caso expone las tres señales que nos dimos, y lo que cada una ahorró en una jornada de trabajo corriente: una funcionalidad rota de la que nadie se quejó — información sobre la funcionalidad, no sobre el fallo; 1.400 traducciones que no escribimos porque ningún lector podía alcanzarlas; y una carencia de supervisión que resultó ser una carencia de ensayo, no de herramienta.

También dice lo que esas señales no significan. «Nadie lo necesita» es la excusa perfecta para no hacer nada, y una regla que solo sabe decir que no ha dejado de ser una regla. Dos salvaguardas la mantienen honesta — entre ellas esta: una funcionalidad sin uso a veces está mal expuesta, no es inútil.

Subir el SO bajo Docker: lo que sigue acoplado y lo que nada valida

2026-09-27T00:00:00+00:00

Show me the REX funciona en un único anfitrión: un Postgres, un Redis, un proxy frontal y la aplicación desplegada en blue-green — dos instancias idénticas, «azul» y «verde», de las que solo una sirve tráfico a la vez. La nueva versión se arranca en la que está en reposo y, cuando responde bien, se conmuta el proxy. Cuando escribimos esto, ese anfitrión sirve 52 casos publicados y algo más de 16.000 visualizaciones acumuladas.

Este montaje protege una entrega: si la nueva versión se porta mal, volver atrás lleva un segundo y nadie se entera. No protege nada frente a la máquina misma, porque las dos instancias viven en ese mismo anfitrión — si se para, se paran las dos.

El anfitrión único es una decisión asumida, no un descuido: sin redundancia mientras el tráfico no la justifique, y con el umbral de revisión por escrito — mil visitas al día. Por debajo, una segunda máquina cuesta mucho más en complejidad (replicación, conmutación, coherencia) de lo que aporta en disponibilidad, y la complejidad que nadie necesita todavía es lo más caro que se puede construir.

Pero asumir esa decisión crea una obligación. Si aceptas que un reinicio corta el servicio, te debes una cifra exacta de lo que cuesta. Eso es lo que hicimos mal esa noche, y volvemos sobre ello al final.

Subimos ese anfitrión de una versión de Ubuntu a la siguiente. La operación salió bien, y eso no es lo interesante. Lo interesante es que la contenerización ha reducido lo que una subida así puede romper a una lista muy corta, y que encontramos justo el elemento de esa lista que nada en nuestra cadena vigilaba.

Lo que la contenerización desacopló de verdad

La aplicación es inmune a una subida de distribución, y conviene precisar por qué: no usa nada del anfitrión. Su PHP, sus extensiones, sus bibliotecas de sistema y su almacén de certificados viajan dentro de la imagen. Se puede sustituir por completo el ca-certificates del anfitrión: nuestras llamadas salientes a VIES, a la pasarela de pago y al almacenamiento de objetos no se enteran, porque nunca leen ese almacén.

Por eso los equipos han acabado tratando una subida de SO en un anfitrión de contenedores como rutina. Es casi cierto, y es ese «casi» el que cuesta.

Los cuatro puntos de acoplamiento que quedan

Cuando ya has metido en imágenes todo lo que se podía, lo que sigue perteneciendo al anfitrión es una lista corta, y es la misma en cualquier servidor contenerizado:

El núcleo. Los contenedores lo comparten. Un salto mayor cambia el suelo bajo una base de datos mucho más que bajo un proceso web.
El demonio Docker. No está en tu imagen: es un paquete del anfitrión, instalado desde un repositorio de terceros.
Las fuentes apt de ese demonio. Lo que decide si el punto anterior volverá a recibir algún parche de seguridad.
El contrato de reinicio. Qué contenedores vuelven solos tras un arranque y cuáles, deliberadamente, no — la instancia en reposo, por ejemplo, debe quedarse abajo, o dos versiones de la aplicación se pelearían por la misma base de datos.

Nada más importa realmente. La lista es lo bastante corta como para revisarla a mano, antes y después — lo que hace imperdonable no revisarla.

El único daño duradero cayó en el punto tres

Una subida de versión desactiva o elimina las fuentes apt de terceros. No es un fallo: esas fuentes están compiladas para la versión que abandonas, y mantenerlas activas durante el salto es la forma de romper el sistema. La herramienta hace bien, y lo advierte.

Lo que no hace es decírtelo después. Nuestra fuente de Docker había desaparecido. Nada se rompió: el demonio siguió funcionando, los contenedores con él, el sitio sirviendo. Pero el paquete instalado estaba compilado para la distribución anterior, y ya no quedaba ningún repositorio capaz de reemplazarlo. El modo de fallo no es un servicio que se detiene; es un gestor de paquetes que se vuelve autoritativo y vacío a la vez. Informa de que todo está al día, y dice la verdad sobre un universo que ya no puede ver.

Restaurar la fuente son cuatro líneas y ningún reinicio. Reveló de inmediato siete versiones menores de deriva acumuladas en silencio. Nada habría levantado la mano jamás: ni el demonio, que funciona; ni la monitorización que no tenemos; ni apt, que ya no tenía con qué comparar.

El punto ciego: los ficheros compose

Y llegamos al hallazgo estructural, que es el que merece llevarse.

Nuestro servicio de base de datos no tenía política de reinicio. Tras un arranque, todos los demás contenedores habrían vuelto y Postgres no. El fallo es trivial: falta una línea. Su vida útil no lo es: llevaba meses ahí, y solo podía manifestarse en un reinicio del anfitrión, que no había ocurrido en todo ese tiempo.

La pregunta buena no es cómo se escribió. Es por qué nada lo detectó. Y la respuesta se generaliza mucho más allá de nuestro montaje: los ficheros compose son la única configuración de producción que nadie posee. No se cuecen en la imagen, así que la construcción nunca los ve. Ningún test los ejercita, porque los tests corren contra la aplicación, no contra la topología del anfitrión. Y nuestro job de despliegue ni siquiera los copia: abre una sesión SSH y lanza un script. Se editan en el repositorio, se aplican a mano y no los valida nada.

En una cadena por lo demás totalmente automatizada —tests, análisis estático, construcción de imagen, despliegue sin corte— ahí es donde un defecto puede dormir indefinidamente. No en el código que el pipeline lee veinte veces al día, sino en el puñado de líneas YAML que no abre nunca.

Lo que el núcleo pudo romper, y lo que no verificamos

Un salto mayor de núcleo bajo un Postgres contenerizado merece algo más que «volvió a arrancar». Hay tres preguntas que hacerse, y solo podemos responder a dos:

El directorio de datos. Vive en un volumen con nombre, en el mismo sistema de ficheros, con el mismo driver de almacenamiento. Nada se movió, y esa es la razón de que la subida fuera superable, no la suerte.
Los perfiles de confinamiento del demonio. Los valores por defecto de seccomp y AppArmor vienen con el paquete Docker, no con la distribución, y por eso los contenedores encontraron el mismo entorno al otro lado.
La semántica de durabilidad. Si un núcleo nuevo cambia algo para Postgres con nuestras opciones de montaje es una pregunta que no respondimos. Aguantó, lo que no prueba nada. Lo escribimos en lugar de reclamar una verificación que nunca hicimos.

La medición ya existía

Queda la obligación planteada en la introducción: conocer el coste real del corte que decidimos aceptar. Dimos una cifra leyendo los registros de los contenedores: el intervalo entre el último error de un proceso y el arranque del siguiente. Ese número describe el anfitrión, no a los visitantes. Deja fuera el apagado anterior y el calentamiento posterior, y puede errar por un factor de tres.

Mientras tanto, todo nuestro tráfico pasa por una CDN que ya había registrado, petición a petición, exactamente lo que recibió la gente en esa ventana. La medición que creíamos que nos faltaba ya la habían tomado por nosotros, en un aparato que pagábamos y nunca habíamos consultado.

El reflejo a corregir no es «añadir instrumentación». Es inventariar lo que ya mide antes de añadir nada: la CDN, los registros del propio proxy, la consola del proveedor. Nuestros tropiezos de procedimiento de esa noche —un nombre de contenedor adivinado, variables de shell que no sobreviven a una reconexión SSH, un grep tan amplio que informó de 41 líneas para 2 errores— son todos de la misma familia y valen exactamente una frase: un runbook resuelve lo que necesita, nunca lo congela. Qué instancia está sirviendo es el caso de manual: cambia en cada despliegue.

Por qué lo publicamos todo — y lo único que nos callamos

Un caso solo sirve si es concreto, así que este lleva las órdenes, los modos de fallo y las lagunas. Lo que plantea una pregunta legítima: ¿publicar todo eso no es entregarle un mapa a un atacante?

Nuestra regla cabe en una frase. El problema nunca es nombrar una versión. Es nombrar una versión en la que sigues siendo vulnerable.

«Estábamos en la versión X, nos costó esto, ya está corregido» es práctica habitual de post-mortem. El mismo texto publicado antes de la corrección es una debilidad todavía vigente con la diana puesta: un caso va firmado, nombra una empresa y un dominio. Así que primero corregir, después contar, y generalizar lo que no enseña nada. La distancia —siete versiones de deriva silenciosa— es la lección; la cadena de versión exacta de nuestro servidor no lo es. Lo que nunca se publica es la otra categoría, la que no se aprende pero sí se copia: nombres de máquina, rutas, la cadena de claves que descifra una copia. La frontera no es «sensible o inofensivo», es ¿esto enseña, o esto abre?

Lo que dio de sí

Cuatro puntos de acoplamiento aislados entre una aplicación contenerizada y su anfitrión: núcleo, demonio, fuentes apt del demonio, contrato de reinicio. Lo bastante pocos para revisarlos a mano, antes y después.
Una vía de actualización congelada, restaurada: el demonio había derivado siete versiones menores sin que nada pudiera señalarlo.
Un punto ciego estructural, nombrado: los ficheros compose, la única configuración de producción que ninguna construcción, ningún test y ningún despliegue llegan a leer.
Una medición recuperada en lugar de construida: la CDN ya había registrado lo que vieron los visitantes, gratis.

Buenas prácticas

Escribe tus puntos de acoplamiento una vez. En un anfitrión de contenedores son cuatro, siempre los mismos, y revisarlos lleva diez minutos.
Tras una subida de versión, revisa primero las fuentes de terceros: un gestor de paquetes sin nada con qué comparar informa de que todo está al día, y no miente.
Busca lo que tu automatización no posee. En una cadena totalmente automatizada, el defecto que sobrevive está en el fichero que el pipeline no abre nunca.
Inventaría lo que ya mide —CDN, proxy, consola del proveedor— antes de añadir instrumentación. La cifra que te falta suele estar ya registrada.
Un runbook resuelve, nunca congela: qué instancia está sirviendo, su nombre de contenedor y el id del servicio se piden en el momento.

Puntos de vigilancia

El fallo peligroso no es el servicio que se detiene, es el que sigue funcionando mientras pierde su capacidad de ser actualizado. No emite nada.
«Volvió a arrancar» no prueba nada sobre durabilidad. Escribe las preguntas que no respondiste en vez de reclamar una verificación que no hiciste.
Un defecto que solo puede manifestarse en un reinicio del anfitrión vive lo que dura el intervalo entre dos reinicios. En un servidor que se porta bien, son meses.
Un registro interno dice cuándo murió un proceso, nunca cuándo dejaron de ser servidos los visitantes. Eso solo lo dice una medición tomada por delante de la pila.
Corrige antes de contar: un caso que describe una debilidad todavía abierta, firmado con tu nombre, no es transparencia: es un manual de instrucciones.

Construir un SaaS completo y listo para producción con un agente de código

2026-09-26T00:00:00+00:00

Cómo diseñamos, aseguramos y desplegamos una plataforma entera — conmutación blue-green sin corte, domiciliaciones reales, acceso con passkey, sitio trilingüe, copias de seguridad cifradas — trabajando en pareja con un agente de código.

El caso detalla la arquitectura elegida, lo que el agente aceleró de verdad y, sobre todo, los puntos en los que hubo que retomar el control.

Garantizar casos legítimos sin equipo de moderación

2026-09-25T00:00:00+00:00

Una plataforma de casos vale exactamente lo que vale la confianza depositada en lo que allí se publica. Un solo caso falso y la credibilidad de todo el corpus se tambalea. La pregunta que nos ocupaba: ¿cómo garantizar la legitimidad de cada publicación, a escala, sin montar un equipo de moderación — y sin delegar el filtrado en una IA, que juzga la forma de un texto y no la legitimidad de quien lo publica?

Nuestra respuesta sustituye la moderación del contenido por la verificación del emisor: sin empresa, no hay publicación; se exige una sustancia mínima; el número de IVA intracomunitario se valida en el registro europeo; y todo queda trazado.

El caso cuenta además las dos trampas que encontramos por el camino, ambas de la misma familia: un servicio de terceros que responde 200 OK sin haber podido verificar nada, y después un estado «desconocido» que en realidad cubría dos situaciones opuestas — «no he podido verificar ahora» y «nunca podré verificar este valor». La segunda dejó pasar cualquier cadena de caracteres durante meses.