Capítulo 3 · Bounded Concerns Architecture

Los Capítulos 1 y 2 establecieron la frontera y describieron el destino. La Línea Nadella separa dos futuros del software, y el Mundo Agentivo es el lado al que las organizaciones cruzarán durante la próxima década. Pero antes de describir la arquitectura del destino — tarea del Capítulo 4 — hay que mirar con cuidado el lugar desde el cual se parte. La inmensa mayoría de las organizaciones que cruzarán la línea no lo harán construyendo desde cero: lo harán transformando un patrimonio de sistemas empresariales que llevan décadas operando, sostienen el corazón del negocio, y no pueden apagarse durante la travesía.

Este capítulo describe ese punto de partida con el mismo rigor con que el resto del libro describe el destino. El instrumento que vamos a usar se llama Bounded Concerns Architecture — abreviado BCA. No es una arquitectura del Mundo Agentivo: es la cartografía formal del estado previo al cruce, diseñada para que un arquitecto pueda mirar un sistema empresarial existente, identificar dónde vive cada responsabilidad, y razonar disciplinadamente sobre qué componentes migrarán al Mundo Agentivo, qué componentes desaparecerán, y qué componentes permanecerán como infraestructura backend invisible que los agentes consumirán sin que el humano la vea jamás.

La elección del nombre no es ornamental. Bounded — acotado — captura el principio operacional que sostiene la arquitectura completa: cada responsabilidad ocupa su lugar y no se desborda al territorio de la responsabilidad vecina. Esa disciplina, que en la era pre-agentiva era buena práctica recomendada, se vuelve condición de viabilidad apenas el sistema empieza a incorporar componentes agénticos. Sin esa disciplina, la volatilidad estadística que los agentes traen consigo contamina el núcleo estable del negocio, y lo que llevaba veinte años funcionando deja de ser confiable. Con esa disciplina, la incursión agéntica queda confinada a la capa que está diseñada para tolerar volatilidad, y el núcleo del negocio queda protegido durante toda la travesía.

BCA es la arquitectura de la transición, no la del destino. Describe el estado desde el cual se cruza la Línea Nadella, no el estado al que se cruza.

La era Agentic exige tratamiento arquitectónico explícito

La incorporación de agentes a sistemas empresariales no es la adición de una nueva tecnología más. Es la introducción de una clase de comportamiento cuya naturaleza es estructuralmente distinta del código tradicional, y que por tanto exige tratamiento arquitectónico distinto.

El código tradicional — workflows, motores de reglas, clases de servicio, scripts de orquestación — tiene una propiedad común: su comportamiento está especificado explícitamente por humanos. Alguien escribió, paso a paso, qué pasa cuando, en qué orden, con qué condiciones. Para entender qué hace, basta leer el código. Su evolución es deliberada: cuando cambia, alguien decidió cambiarlo y modificó el código correspondiente.

El código agéntico — agentes basados en modelos de lenguaje, sistemas de recomendación, optimizadores de aprendizaje automático, sistemas expertos — tiene una propiedad opuesta: su comportamiento está derivado contextualmente desde un modelo. Nadie programó paso a paso qué hace; alguien describió un objetivo o un patrón, y la entidad deriva el comportamiento desde sus pesos, datos de entrenamiento, prompts o reglas heurísticas. Para entender qué hace, no basta leer el código — hay que entender los datos o el modelo del que el comportamiento emerge. Su evolución es estadística: cuando cambia, no es porque alguien modificó una línea sino porque cambiaron los datos, los pesos o los prompts que sintetizan el razonamiento.

Esta diferencia tiene cuatro consecuencias arquitectónicas concretas que separan a los componentes agénticos de los componentes tradicionales. Los componentes procedurales se prueban con tests unitarios deterministas; los agénticos se prueban con datasets de evaluación y métricas agregadas. Los procedurales producen logs predecibles que reflejan ejecución de código; los agénticos producen logs que requieren interpretación porque el comportamiento varía con el contexto. Los procedurales son auditables línea por línea; los agénticos son auditables por sus inputs, outputs y métricas pero no por su lógica interna. Los procedurales evolucionan mediante refactor de código; los agénticos evolucionan mediante reentrenamiento, ajuste de prompts o cambio de modelos. Estas cuatro propiedades son lo suficientemente distintas como para justificar que la arquitectura las trate como ciudadanos separados.

La amenaza estructural que esta diferencia introduce en el sistema empresarial es la siguiente: los agentes son volátiles, pero las invariantes del negocio no pueden serlo.

Un agente evoluciona rápidamente. Cambia con cada actualización del modelo subyacente, con cada ajuste de prompt, con cada incorporación de nuevas herramientas o nuevos datos. Su comportamiento puede variar entre dos invocaciones idénticas. Su corrección no es binaria sino estadística: opera correctamente la mayoría de las veces, con un umbral de error tolerable que depende del caso de uso.

Las invariantes del negocio son lo opuesto. Un cliente tiene un identificador único. Una factura tiene un total que iguala la suma de sus líneas. Un servicio activado tiene una fecha de activación. Estas reglas no admiten errores estadísticos: o se cumplen siempre o el sistema deja de ser confiable. Su corrección es binaria, su ritmo de cambio es estructural, y su violación tiene consecuencias regulatorias, financieras u operacionales graves.

Cuando un agente y una invariante coexisten en la misma capa arquitectónica sin frontera explícita entre ellos, la volatilidad del primero contamina la confiabilidad de la segunda. Cada actualización del agente arriesga romper invariantes que llevaban años funcionando correctamente. Cada cambio de prompt puede alterar inadvertidamente el cumplimiento de una regla regulatoria. La auditoría se vuelve imposible porque ya no hay separación entre lo que se programó deliberadamente y lo que el agente decidió contextualmente.

La delgadez del dominio como respuesta

La respuesta operacional a esta amenaza es lo que llamaremos la delgadez del dominio. Si el núcleo autoritativo del sistema — donde viven las invariantes y la persistencia de la verdad del negocio — se mantiene estrictamente delgado, admitiendo únicamente lo que es estructural al dominio y expulsando toda lógica volátil hacia afuera, entonces la incursión agéntica queda confinada a la capa que está diseñada para tolerar volatilidad. Los agentes operan en la lógica de orquestación, junto a los workflows procedurales tradicionales, y ambos invocan al núcleo como un servicio con contrato estable. El corazón del negocio queda protegido.

Esta es la posición operacional que sustenta toda la arquitectura. Mantener el dominio delgado no es una preferencia estética sino una condición necesaria para que capacidades procedurales y agénticas puedan coexistir en un mismo sistema sin que la última corroa la confiabilidad de la primera.

La distinción entre Systems of Record y Systems of Engagement, articulada por Geoffrey Moore¹, opera convergentemente con esta tesis pero a un nivel distinto. Moore distingue entre dos categorías de sistemas según su propósito y su ritmo de cambio: los Systems of Record almacenan el estado autoritativo del negocio y obtienen su valor de su confiabilidad, lo cual exige estabilidad; los Systems of Engagement median la interacción y obtienen su valor de su capacidad de adaptación, lo cual exige velocidad. Forrester² extendería más tarde la taxonomía agregando los Systems of Insight, orientados a generación de conocimiento. La dicotomía de Moore opera a nivel de inventario de sistemas — qué sistemas tiene una organización; la delgadez del dominio opera a nivel de organización del código dentro de un componente. Ambas convergen en la misma intuición fundamental, que Buschmann y colegas³ articulan en términos del patrón Layers como criterio de descomposición: cada capa debe tener una responsabilidad distinta y específica respecto a abstracción, granularidad o ritmo de cambio. La era Agentic intensifica esta lógica: los componentes agénticos cambian a un ritmo aún más rápido que las políticas comerciales tradicionales — ritmo de modelo, no ritmo de negocio — y por tanto deben quedar aún más alejados arquitectónicamente del núcleo estable.

La tesis sostiene una posición específica sobre la jerarquía de decisiones arquitectónicas. Otras decisiones frecuentemente debatidas — la elección entre arquitectura monolítica o microservicios, la dirección de las dependencias, el grado de adopción de event sourcing, la separación command/query, la modalidad de despliegue de agentes — son importantes pero subordinadas. Operan dentro de un espacio cuya forma queda determinada antes por la decisión sobre dónde termina el dominio. Una arquitectura de microservicios con dominios obesos donde se introducen agentes reproduce los problemas de un monolito mal estructurado, distribuidos y ahora con volatilidad agéntica adicional. Una arquitectura hexagonal con un núcleo que mezcla invariantes y workflows usa la dirección correcta de las dependencias para proteger un núcleo mal diseñado, pero la incorporación de agentes en ese núcleo invalida la protección. Un dominio delgado, en cambio, produce un componente cuyo núcleo es estable, cuyas reglas son auditables y cuyas integraciones — procedurales o agénticas — son intercambiables.

Mantener el dominio delgado requiere una operación arquitectónica concreta: trazar una frontera explícita entre el dominio y la lógica de orquestación, y defender esa frontera contra el deslizamiento incremental que tiende a engordar el núcleo en el tiempo. El término Bounded del nombre del modelo recoge el principio de Separación de Preocupaciones articulado por Dijkstra⁴: la disciplina de estudiar un aspecto de un problema en profundidad, por su propia consistencia, sabiendo todo el tiempo que es solo uno entre varios. La separación de Dijkstra es originalmente cognitiva. Su transformación en principio arquitectónico durante las décadas siguientes — visible en patrones como Layers⁵, Hexagonal⁶, Clean Architecture⁷ y DDD⁸ — produce el linaje teórico al que pertenece BCA. La diferencia entre BCA y sus predecesoras está en qué frontera específica se elige como la más consecuente: BCA elige la frontera del dominio, y la sostiene como condición de viabilidad para la era Agentic.

Las tres capas

BCA descompone un componente empresarial en tres capas. La Capa 1, Presentation, contiene las dos fronteras externas del componente: UI hacia humanos y API hacia sistemas. La Capa 2, Business Logic, contiene la lógica de orquestación, organizada en dos cajas paralelas: Procedural para el comportamiento programado explícitamente, Agentic para el comportamiento derivado contextualmente. La Capa 3, Domain, contiene el núcleo estable del componente, organizado en dos dimensiones ortogonales: dominio propio frente a dominio ajeno en el eje vertical, lógica frente a persistencia en el eje horizontal.

La Capa 1 trata UI y API como ciudadanos paralelos, no como variantes del mismo concern. UI son los controladores, vistas y manejadores que median la interacción con humanos; evoluciona al ritmo de las necesidades de UX. API son los endpoints, contratos, mecanismos de routing y políticas de versionado que median la interacción con otros sistemas; evoluciona al ritmo de los contratos públicos del componente, bajo restricciones específicas de retrocompatibilidad y semántica precisa⁹. En la era pre-agentiva esta separación era buena práctica de microservicios; en la era Agentic cobra relevancia adicional, porque los agentes pueden operar tanto sobre la UI (asistiendo al usuario humano) como sobre la API (consumiendo y produciendo contratos máquina-a-máquina), y reconocer la distinción permite gestionar adecuadamente sus respectivos modos de invocación.

La Capa 2 contiene la lógica de orquestación: la lógica que sabe qué pasos componen un caso de uso, en qué orden ocurren, qué ocurre si uno falla. Aquí vive la séptima separación canónica del modelo, sobre la que vamos a volver con detalle más adelante. Procedural comprende toda la lógica cuyo comportamiento está programado explícitamente por humanos: motores de procesos, motores de reglas, sagas, choreography frameworks, orquestadores de workflows, clases de servicio, scripts de coordinación. La distinción operativa no es de tecnología sino de naturaleza: el comportamiento está codificado paso a paso por un humano y puede entenderse leyendo el código línea por línea. Agentic comprende los componentes cuyo comportamiento se deriva contextualmente desde un modelo, no desde una secuencia codificada. Las dos cajas comparten capa porque ambas son lógica de orquestación — ambas operan sobre el dominio sin formar parte de él — pero su naturaleza operacional distinta justifica el tratamiento como ciudadanos paralelos.

La frontera entre la Capa 2 y la Capa 3 — entre orquestación y dominio — es la frontera operacional de la tesis. La Capa 3 contiene exclusivamente lógica que el negocio considera estructural; todo lo demás vive en la Capa 2, sea Procedural o Agentic. El criterio operativo es de naturaleza temporal: si una regla puede cambiar como consecuencia de una decisión comercial sin alterar el modelo fundamental del negocio — o si la regla es derivada estadísticamente y no explícitamente codificada — pertenece a la Capa 2; si la regla es estructural al dominio y cambiarla implicaría un cambio en la naturaleza misma del negocio, pertenece a la Capa 3.

La Capa 3 se organiza en dos dimensiones ortogonales que producen cuatro celdas. La dimensión vertical separa el dominio propio del ajeno: la columna SOR (System of Record) contiene los componentes que modelan datos cuya autoridad pertenece al sistema — el núcleo autoritativo, lo que se valida, lo que se persiste como verdad, lo que emite eventos cuando cambia; la columna External contiene los componentes que conocen, traducen y representan localmente datos cuya autoridad vive afuera, en sistemas con los que el componente colabora — CRMs, billing externo, OSS de provisión, partners B2B, APIs de terceros. La dimensión horizontal separa la lógica de la persistencia: la banda Logic contiene las invariantes en SOR y las traducciones desde el modelo ajeno en External; la banda Persistence contiene los mecanismos físicos de almacenamiento.

Cada una de las cuatro cajas resultantes se subdivide internamente en una vía síncrona y una vía asíncrona. La asimetría léxica entre Streams (lado SOR) y Hooks (lado External) es deliberada. En el lado SOR el sistema emite hechos propios y los persiste como un log apendable; la autoría es propia y la dirección es saliente. En el lado External los eventos llegan porque sistemas externos los empujan mediante webhooks o equivalentes; la autoría es ajena y la dirección es entrante. Llamar a ambos Streams perdería esa información direccional importante.

Las siete separaciones estructurales

Tomadas en conjunto, las decisiones de las tres capas producen siete separaciones estructurales explícitas. Cada una responde a la observación clásica de que las preocupaciones diferenciadas tienen ritmos de cambio distintos, audiencias distintas y semánticas distintas, y por tanto merecen tratamiento arquitectónico distinto.

La separación 2 es la frontera operacional de la tesis. Las separaciones 3 a 6 estructuran el contenido interno de la Capa 3. La separación 1 estructura el contenido interno de la Capa 1. Y la separación 7 — la séptima separación canónica — estructura el contenido interno de la Capa 2 reflejando explícitamente la naturaleza dual de la lógica de orquestación en la era Agentic.

Cada celda de la arquitectura tiene su propio ritmo de cambio. SOR · Logic y SOR · Persistence cambian al ritmo de la evolución del modelo del negocio fundamental — años o décadas. External · Logic y External · Persistence cambian al ritmo de los sistemas externos a los que sirven. Business Logic Procedural cambia al ritmo de las políticas comerciales — meses. Business Logic Agentic cambia al ritmo de los modelos subyacentes — semanas o días. API cambia al ritmo de los contratos públicos. UI cambia al ritmo de las necesidades de UX. Esta diferenciación justifica políticas de versionado, despliegue y testeo distintas para cada celda, y es la razón estructural por la que la séptima separación es necesaria: el ritmo Agentic es lo suficientemente rápido como para requerir su propio régimen.

Genealogía intelectual

BCA no inventa primitivas. Sintetiza patrones publicados, debatidos y refinados por la comunidad de arquitectura de software durante las últimas dos décadas, los reorganiza alrededor de un principio operacional explícito — la delgadez del dominio — y los reposiciona en relación con un fenómeno emergente: la incorporación de capacidades agénticas en sistemas empresariales. Cada decisión del modelo se ancla en literatura previa.

La frontera entre las Capas 2 y 3 — entre orquestación y dominio — proviene directamente de Fowler¹⁰. En Patterns of Enterprise Application Architecture, Stafford —autor del patrón Service Layer en esa obra— articula la distinción entre domain logic, que tiene que ver puramente con el dominio del problema, y application logic, que tiene que ver con responsabilidades de aplicación como notificaciones, integraciones y workflows. Fowler refuerza la distinción en Domain Logic and SQL¹¹ y reconoce sus límites prácticos en Organizing Presentation Logic¹². La separación entre lógica y persistencia dentro de la Capa 3 se desprende de los patrones Data Mapper y Repository¹³, cuyo propósito explícito es mantener el modelo del dominio limpio de detalles de almacenamiento.

El Domain Layer como contenedor de invariantes proviene de Evans¹⁴. En Domain-Driven Design propone una arquitectura de cuatro capas (UI / Application / Domain / Infrastructure) que coincide estructuralmente con BCA, con dos diferencias deliberadas: BCA bifurca el dominio en SOR y External, incorporando explícitamente la integración con sistemas ajenos como ciudadana plena del dominio; y BCA separa la persistencia del dominio dentro de la misma capa, mientras que en Evans la persistencia queda en Infrastructure.

BCA se aparta deliberadamente del DDD canónico en un punto específico: la ubicación de los Domain Services. Bajo DDD canónico, los Domain Services — la lógica que coordina múltiples agregados — pertenecen al Domain Layer. BCA los ubica en Business Logic. La razón es la asimetría temporal articulada antes: los Domain Services contienen frecuentemente políticas comerciales que cambian con el negocio (políticas de elegibilidad, reglas de descuento, procedimientos de aprobación), mientras que las invariantes estructurales del dominio cambian a un ritmo fundamentalmente más lento. En la era Agentic esta asimetría se intensifica: parte de la coordinación pasa a ser responsabilidad de agentes, lo cual añade volatilidad estadística a la volatilidad temporal ya presente. Vernon¹⁵ discute la tensión entre Domain Services y Application Services sin resolverla en una sola dirección, reconociendo que la elección depende del contexto. BCA toma posición.

La filosofía de la pierna asíncrona se ancla en Helland¹⁶. Data on the Outside vs. Data on the Inside articula que los datos autoritativos viven dentro de un servicio en un mundo transaccional con cambios serializables, mientras que los datos que circulan entre servicios son inmutables. Una década más tarde, en Immutability Changes Everything¹⁷, Helland profundiza: los hechos del dominio son intrínsecamente inmutables — los eventos que ocurren no pueden borrarse; las correcciones son nuevos eventos. Kleppmann¹⁸ sintetiza esta tradición articulando que estado mutable y log de eventos pueden coexistir como representaciones complementarias del mismo dominio, posición que es la base conceptual de la coexistencia de Repository y Streams en la columna SOR de BCA.

Young¹⁹ articula CQRS defendiendo que el lado de comandos debe ser delgado y centrado en proteger invariantes; la lógica de procesos vive en sagas y process managers que coordinan los SoR, no dentro de ellos. BCA adopta el espíritu de CQRS sin llegar al CQRS estricto: las celdas síncronas de la Capa 3 están delgadas, las celdas asíncronas existen como ciudadanas complementarias, pero el estado mutable y el event log coexisten en lugar de uno derivar del otro. Fowler²⁰ sintetiza la posición de Young en su entrada de bliki sobre CQRS.

La columna External de la Capa 3 generaliza el patrón Anti-Corruption Layer originalmente propuesto por Evans²¹ y refinado por Vernon²² con foco específico en cómo se integran bounded contexts entre sí. Vernon articula explícitamente que la integración con sistemas legados es uno de los casos paradigmáticos donde el patrón aplica.

La separación de la API como concern arquitectónico distinto no aparece en los textos clásicos de Fowler²³, Evans²⁴ o Moore²⁵, pero es práctica establecida en arquitectura de microservicios moderna. Newman²⁶ dedica capítulos enteros a las decisiones de diseño de API, separándolas explícitamente de la presentación al usuario. La pierna asíncrona se apoya en el catálogo formal de patrones de mensajería de Hohpe y Woolf²⁷ — sus 65 patrones constituyen el vocabulario de las celdas Events, Streams y Hooks. En el contexto telco específicamente, el TM Forum²⁸ clasifica los bloques funcionales de la Open Digital Architecture según la dicotomía de Moore: Party Management, Core Commerce Management y Production como SoR; Engagement Management como SoE; Intelligence Management como SoI. La adopción de la columna SOR en BCA es coherente con esta clasificación: si TMF ya define ciertos bloques funcionales como SoR, tiene sentido que la lógica que reside dentro de ellos sea consistente con el propósito de un SoR según Moore.

La séptima separación canónica — Procedural / Agentic — y el reposicionamiento del modelo como arquitectura del estado pre-agentivo se anclan en El Futuro Agentivo²⁹ y en este libro. Allí se articula la Línea Nadella como frontera conceptual entre dos mundos posibles para el software empresarial. BCA toma posición específica: es la arquitectura de la transición Agentic, y cede el lugar al marco de la Arquitectura Agentiva del Mundo Agentivo (Capítulo 4) cuando la organización cruza la línea.

Mapa comparativo de propuestas

Las propuestas mencionadas en la genealogía conviven en la conversación arquitectónica como un archipiélago donde cada autor traza líneas en lugares distintos. La figura siguiente las ubica en un mapa bidimensional que permite visualizar cómo se relacionan entre sí y por qué la posición de BCA es una elección, no la única opción razonable.

El mapa se construye sobre dos dimensiones cuya naturaleza metodológica es deliberadamente distinta. El eje X es medible según una escala discreta de cinco niveles. El eje Y es cualitativo y se construye mediante una inferencia interpretativa que la sección siguiente formaliza.

El eje X — Grosor del dominio mide cuánta lógica acumula el componente que maneja datos autoritativos. Los niveles son acumulativos: cada nivel incluye lo que está en los niveles inferiores. Nivel 0 — DAO puro: solo CRUD sobre el almacenamiento, sin invariantes ni auditoría; no califica como dominio en sentido estricto. Nivel 1 — Dominio estricto: añade invariantes intrínsecas del agregado, identidad estable y auditoría de cambios. Es el grosor que la tesis defiende como óptimo para la era Agentic. Nivel 2 — Multi-entidad: añade operaciones que coordinan varios agregados del mismo dominio (Domain Services). Nivel 3 — +políticas: añade reglas comerciales cambiables (campañas, descuentos, restricciones de elegibilidad). Nivel 4 — +workflows: añade orquestación de procesos completos con múltiples pasos e integraciones externas.

El eje Y — Rigor teórico vs flexibilidad real mide qué tan dogmática es la propuesta sobre exigir su separación. En el polo purista están las propuestas que sostienen “si no separas estrictamente, no estás haciendo X de verdad”. En el polo pragmático están las propuestas que reconocen explícitamente que la línea conceptual se ensucia en la práctica. El polo pragmático refleja exactamente el caveat que Fowler³⁰ reconoce sobre las arquitecturas en capas.

Las posiciones reflejan la postura del autor original de cada propuesta, no las interpretaciones que las distintas comunidades han hecho de ellas. En el cuadrante superior-izquierdo — puristas con núcleo mínimo — viven CQRS estricto³¹ y Data on the Inside³². Ambas propuestas exigen un dominio delgado y son dogmáticas al respecto. En el cuadrante superior-medio — puristas con marcos arquitectónicos — viven Clean Architecture³³ y Hexagonal³⁴. Ambas definen reglas estrictas sobre la dirección de las dependencias y la separación entre dominio e infraestructura, pero permiten cierta riqueza multi-entidad dentro del núcleo. En el cuadrante superior-derecho — purista con núcleo grueso — vive DDD canónico³⁵, refinado por Vernon³⁶. Acumula más lógica dentro del Domain Layer mediante Domain Services pero con disciplina estricta sobre Bounded Contexts, Anti-Corruption Layers y agregados bien delimitados.

En la zona intermedia se ubica Bounded Concerns Architecture. En el eje X coincide con CQRS y Helland (nivel 1, dominio estricto). En el eje Y queda en zona intermedia: adopta la formalidad de Fowler y Moore en la frontera del dominio (qué entra y qué no), pero es pragmática sobre la implementación interna del componente, reconociendo que en sistemas empresariales con productos COTS no se tiene control sobre la organización interna del software comprado, y que en la era Agentic los componentes Agentic introducen una capa adicional de variabilidad que requiere flexibilidad operacional.

En el cuadrante inferior-medio — pragmático declarado — vive Service Layer³⁷. Es la propuesta más explícitamente pragmática de las maduras: el propio Fowler³⁸ escribe que la distinción entre application logic y domain logic se ensucia en la práctica. En el cuadrante inferior-derecho — pragmáticos con núcleo grueso — viven Active Record³⁹ y 3-layer clásico⁴⁰. Active Record fue diseñado para productividad — el lema “convención sobre configuración” de Rails es su ethos. El 3-layer clásico, sin disciplina arquitectónica adicional, tiende a acumular workflows enteros dentro de la capa de Business Logic mezclados con persistencia.

El mapa es una herramienta de orientación, no una clasificación oficial. Tres precauciones de lectura. Primera, las posiciones reflejan la postura del autor original; distintas comunidades han interpretado las mismas propuestas con mayor o menor rigor (existe DDD-lite y existe DDD ortodoxo). Segunda, el eje Y es cualitativo y depende de una inferencia interpretativa que la siguiente sección formaliza. Tercera, este mapa cubre propuestas para organizar el interior de un componente; no habla de patrones de integración entre componentes, que son ortogonales y están catalogados en otros trabajos⁴¹⁴².

Modelo de scoring para el eje cualitativo

El eje Y del mapa ubica las propuestas en una dimensión cualitativa de “rigor teórico vs flexibilidad real”. Esta posición no proviene de las fuentes — Fowler nunca escribió que CQRS es más purista que Service Layer en términos formales — es una inferencia interpretativa construida a partir de la lectura de las fuentes.

Para que esa inferencia sea verificable y discutible, el “pragmatismo” se descompone en cinco dimensiones observables, cada una puntuable de 0 a 3 según criterios textuales explícitos. La suma resultante (0 a 15) ubica a cada propuesta en el eje Y, donde 0 representa máximo rigor purista y 15 representa máxima flexibilidad pragmática. Este modelo no pretende producir un score definitivo. Pretende hacer visible y disputable el razonamiento que llevó a cada ubicación. Cualquier lector con acceso a las fuentes primarias puede recalibrar las celdas y obtener una posición distinta — eso es deseable, no un defecto.

D1 — Lenguaje normativo. ¿La propuesta usa frases del tipo “debes / nunca / siempre / strict / must” sobre la separación, o usa “considera / muchas veces / depende / a menudo”? D2 — Reconocimiento del gris práctico. ¿La propuesta admite explícitamente casos donde aplicar la regla causa daño, o defiende la pureza ante todo escenario? D3 — Permisividad ante variantes lite. ¿Existen variantes flexibles toleradas o promovidas por el autor original? D4 — Foco. ¿La propuesta pretende reorganizar todo el sistema, o se ofrece como un patrón entre muchos en una caja de herramientas? D5 — Compatibilidad con sistemas legados. ¿La propuesta ofrece caminos para integrarse con sistemas existentes que no la siguen, o exige greenfield?

La aplicación a las propuestas evaluadas produce los scores de la tabla siguiente.

Los scores producen una correlación que sustenta la tesis del capítulo. Las propuestas con menor score en el eje Y (CQRS estricto: 4/15; Clean Architecture: 4/15; Data on the Inside: 5/15) son también las que mantienen los dominios más delgados cuando se aplican con disciplina. Las propuestas con mayor score (Service Layer y Active Record: 13/15 ambas) tienden a producir dominios variables porque su flexibilidad lo permite.

BCA ocupa una posición intermedia (9/15) que la tesis defiende como pragmáticamente óptima en contextos empresariales con sistemas legados y capacidades agénticas en incorporación: suficientemente firme en la frontera del dominio como para preservar su delgadez, suficientemente flexible en la implementación interna como para coexistir con software comprado, motores de procesos heredados y agentes de naturaleza estadística sobre los cuales no se tiene control arquitectónico tradicional.

Caso de aplicación · Activar el servicio de banda ancha de un cliente nuevo

Para hacer tangibles las tres capas y la distribución de responsabilidades — incluida la séptima separación Procedural / Agentic — considérese un caso del dominio de las telecomunicaciones: la activación del servicio de banda ancha de un cliente nuevo. Es un workflow representativo de las operaciones cotidianas bajo el marco TM Forum ODA⁵⁰ que toca tanto el dominio propio (cliente, servicio, suscripción) como dominios ajenos (OSS de provisión de red, billing externo, proveedor de email), y se enriquece en la era actual con la incorporación de un asistente conversacional que apoya al agente de call center y un generador automatizado de contenido para la comunicación al cliente.

La distribución de las acciones entre las celdas de BCA es la siguiente:

Cinco observaciones se desprenden de esta distribución. Primera, la mayoría del comportamiento vive en Business Logic, distribuido entre Procedural y Agentic. Solo cuatro de las quince acciones tocan el dominio propio, y dos tocan el dominio ajeno; las nueve restantes viven en la Capa 2 o en Presentation. La era Agentic añade naturaleza al comportamiento de la Capa 2 sin tocar el núcleo del dominio. Segunda, Procedural y Agentic coexisten naturalmente en la misma capa: las dos acciones agénticas no están aisladas en una capa especial ni son tratadas como casos excepcionales — son ciudadanos plenos de Business Logic, intercalados con las acciones procedurales según la lógica del workflow. Tercera, las acciones agénticas no tocan el dominio: operan exclusivamente en Business Logic, toman como input información del dominio y producen output que vuelve a la Capa 2 o a la Capa 1, pero nunca modifican directamente el estado autoritativo del SOR. Es la materialización operacional de la tesis: las invariantes del dominio quedan protegidas de la volatilidad agéntica porque la frontera entre las Capas 2 y 3 es respetada estrictamente. Cuarta, las dos vías de comunicación coexisten naturalmente: las acciones síncronas usan las celdas síncronas de cada caja, las acciones asíncronas usan las celdas asíncronas, y ningún workflow está obligado a usar exclusivamente una vía u otra⁵¹. Quinta, el núcleo del dominio queda intacto y delgado: las cuatro acciones marcadas con SOR son precisamente lo que la tesis identifica como núcleo autoritativo — invariantes y persistencia, con sus contrapartes asíncronas. Toda la lógica volátil — sea procedural o agéntica — vive afuera del dominio.

Implicaciones arquitectónicas

La adopción de BCA tiene implicaciones específicas para el diseño de componentes empresariales en la era Agentic. Los componentes que cumplen rol de SOR deben exponer APIs delgadas centradas en operaciones que preservan invariantes, coherente con la visión de Young⁵² sobre el lado de comandos en CQRS. Los componentes de orquestación procedural y agéntica deben ser explícitos y separados; no deben estar disfrazados como extensiones del dominio. La persistencia debe ser intercambiable sin tocar la lógica del dominio. Los componentes de integración (Gateway, Proxies, Events, Hooks) deben tratarse como modeladores de un dominio ajeno⁵³⁵⁴. Los componentes asíncronos (Events, Streams, Hooks) deben tratarse como ciudadanos plenos del diseño con su propia lógica de versionado, su propia semántica de entrega y sus propios SLAs⁵⁵.

La ubicación de la lógica de IA y agentes autónomos merece atención específica. Los componentes de inteligencia y agentes — orquestadores basados en modelos de lenguaje, recomendadores, optimizadores, sistemas expertos — son por naturaleza lógica de procesos coordinadores. Su lugar correcto en BCA es la caja Agentic dentro de Business Logic, no Domain. Esto preserva la estabilidad del SOR mientras permite que la lógica agéntica evolucione rápidamente. La pierna asíncrona del dominio (celdas Events, Streams, Hooks) es particularmente útil para integrar agentes: pueden suscribirse a eventos del dominio para reaccionar autónomamente sin acoplarse al núcleo del SOR. La séptima separación dentro de Business Logic permite además aplicar regímenes de gobernanza específicos a cada tipo de componente: testing determinista versus evaluación con datasets, observabilidad línea-por-línea versus métricas agregadas, auditoría por código versus auditoría por inputs/outputs, evolución por refactor versus evolución por reentrenamiento. Estos regímenes diferenciados son críticos para mantener trazabilidad y cumplimiento regulatorio en sistemas que combinan ambos tipos de comportamiento.

La coexistencia de estado mutable y log de eventos es una decisión arquitectónica explícita de BCA. El estado mutable y el log de eventos coexisten como representaciones complementarias del dominio, no como sustitutos. Esto sitúa la propuesta en una posición intermedia entre los sistemas tradicionales — donde solo existe estado mutable y los eventos, si los hay, son emergentes y no autoritativos — y el Event Sourcing puro — donde el estado se reconstruye siempre desde el log de eventos y el estado no es autoritativo, solo derivado. En BCA, el estado mutable es la fuente de verdad principal y el log de eventos es un complemento autoritativo. La técnica de Change Data Capture discutida por Kleppmann⁵⁶ proporciona el mecanismo concreto para mantener ambas representaciones sincronizadas.

Limitaciones del modelo

BCA es una posición arquitectónica entre varias legítimas, no la única. DDD canónico⁵⁷⁵⁸ es una posición arquitectónica respetable y tiene méritos genuinos, especialmente en dominios donde la lógica del negocio es muy rica y se beneficia de quedar concentrada en objetos del dominio. La elección entre DDD canónico y BCA debe hacerse caso por caso, considerando el contexto. La tesis del capítulo sostiene que en la era Agentic BCA produce mejores resultados, pero esta afirmación no se extiende universalmente a todos los contextos.

La frontera del dominio no siempre es nítida en la práctica. Como reconoce Fowler⁵⁹, la distinción entre domain logic y application logic se ensucia en sistemas reales. Habrá casos ambiguos donde no esté claro si una validación es intrínseca al dominio o es política de negocio. El criterio operativo recomendado es de naturaleza temporal — si la regla puede cambiar por una decisión comercial sin alterar el modelo del negocio fundamental, va en Business Logic; si la regla es estructural al dominio, va en SOR · Logic — pero este criterio no elimina la ambigüedad: la hace discutible y resoluble caso por caso.

La frontera entre Procedural y Agentic puede difuminarse. Una limitación específica de la era actual es que la separación entre componentes Procedural y Agentic no siempre es nítida. Un BRMS clásico puede incorporar reglas heurísticas con propiedades estadísticas; un agente moderno puede operar dentro de un workflow procedural rígido. La séptima separación captura una distinción fundamental — origen explícito versus derivación contextual del comportamiento — pero su aplicación práctica requiere juicio en casos límite, particularmente en sistemas híbridos que combinan razonamiento simbólico con inferencia estadística.

BCA no reemplaza a otros marcos. Esta descomposición es complementaria, no sustitutiva, de otros marcos: TM Forum ODA⁶⁰ para clasificación funcional a nivel de inventario de sistemas, principios cloud-native para despliegue, patrones de integración como los catalogados por Hohpe y Woolf⁶¹ para comunicación entre componentes, y el marco de la Arquitectura Agentiva del Mundo Agentivo (Capítulo 4) para sistemas que han cruzado la Línea Nadella. BCA aplica al interior de un componente o conjunto de componentes que operan en el estado pre-agentivo.

Y el modelo de scoring de la sección anterior tiene tres limitaciones reconocidas. Primera, las puntuaciones reflejan interpretaciones del autor sobre los textos de cada propuesta; un evaluador con acceso a las mismas fuentes puede llegar a puntuaciones distintas, especialmente en dimensiones como D2 y D3 que requieren juicio sobre el espíritu de los textos. Segunda, la suma simple de las cinco dimensiones asume implícitamente que tienen pesos iguales, lo cual es una simplificación; en algunos contextos D5 (compatibilidad con legados) puede pesar más que D4 (foco), y viceversa. Tercera, el modelo evalúa la postura del autor original, no la práctica efectiva de las comunidades que adoptan cada propuesta.

Mapping al Mundo Agentivo

Hasta aquí hemos descrito la cartografía del estado pre-agentivo. La pregunta operativa que este libro plantea — y que justifica la presencia de BCA en él — es la pregunta del puente: cuando una organización cruza la Línea Nadella, ¿qué le pasa a cada una de las celdas de BCA? ¿Cuáles migran al Mundo Agentivo y se transforman en algo distinto? ¿Cuáles permanecen como infraestructura backend invisible? ¿Cuáles desaparecen?

La respuesta no es uniforme entre celdas. El cruce afecta a cada una de manera distinta, en momentos distintos, con consecuencias distintas. Lo que sigue es el mapping celda por celda — la pieza que convierte a BCA en instrumento de migración, no en mera descripción del pasado.

Cuatro patrones generales emergen del mapping. Primero, la Capa 3 sobrevive casi intacta. Las invariantes estructurales y la persistencia autoritativa son lo que el sistema empresarial tiene que preservar durante el cruce, y la disciplina de la delgadez del dominio es lo que asegura que sobrevivan. La Capa 3 de BCA es, en buena medida, lo que se vuelve el sustrato de los AgencyDomains del Capítulo 4. Segundo, la Capa 2 se transforma profundamente. La caja Procedural se contrae; la caja Agentic se expande hasta dominar; ambas eventualmente dejan de ser cajas paralelas y se convierten en Botlets que componen comportamiento desde el catálogo de Capabilities. La séptima separación de BCA es la grieta inicial por la cual el Mundo Agentivo entra al sistema empresarial; con el tiempo, esa grieta se ensancha hasta consumir la capa entera. Tercero, la Capa 1 se bifurca. La UI se vacía y eventualmente desaparece como interfaz primaria; la API se intensifica y se transforma en Conector (Capa 4), no en Capability. La transformación es asimétrica: una de las dos cajas de la Capa 1 muere; la otra prospera con un nombre distinto. Cuarto, Trust Infrastructure aparece como concern transversal nuevo que en BCA no estaba materializado. La gobernanza, auditabilidad y políticas de identidad y acceso, que en BCA eran responsabilidades dispersas entre las celdas, se elevan a una capa transversal explícita en el Mundo Agentivo. Esta es una de las contribuciones arquitectónicas del Capítulo 4: hacer visible lo que en la era pre-agentiva quedaba implícito en cada componente.

El mapping también permite contestar preguntas operativas que un arquitecto en transición se hace cotidianamente. ¿Tengo que reescribir mi SOR para entrar al Mundo Agentivo? No: la Capa 3 sobrevive. Lo que tienes que hacer es exponerla con disciplina vía Capabilities. ¿Mis workflows actuales mueren? No todos: sobreviven los que tienen requisitos de trazabilidad regulatoria; los demás se reabsorben en Botlets. ¿Mis APIs actuales sirven? Sí, pero hay que renegociar su contrato como Conector (Capa 4) descubrible y gobernado por Trust Infrastructure. ¿Mis aplicaciones con UI mueren? Las que existían para navegar y filtrar información, sí. Las que producen artefactos especializados, sobreviven más tiempo, eventualmente con copiloto o agente como mediador, según ya describimos en el Capítulo 2.

Cierre · La frontera de BCA

BCA es la arquitectura del estado pre-agentivo. Su valor en este libro es doble. Primero, ofrece una cartografía formal de lo que la mayoría de las organizaciones que cruzarán la Línea Nadella tienen hoy: tres capas, siete separaciones, un núcleo delgado, una orquestación dual entre Procedural y Agentic. Segundo, y más importante, ofrece el instrumento de mapping que permite razonar disciplinadamente sobre qué migra, qué desaparece, qué permanece — y por qué.

Pero BCA tiene una frontera explícita. Cuando una organización cruza la Línea Nadella y entra plenamente al Mundo Agentivo, las separaciones que BCA articula tienden a colapsar. La Capa 1 se convierte en una conversación con un agente. La distinción entre Procedural y Agentic se diluye porque la primera caja se vacía progresivamente. Eventualmente, incluso la frontera entre Business Logic y Domain queda mediada por una entidad agéntica que decide qué pasos invocar. En ese momento, BCA ha cumplido su propósito de transición y cede el lugar a un marco arquitectónico distinto — un marco que ya no se organiza en torno a la separación entre dominio y orquestación, sino en torno a las cuatro capas del Mundo Agentivo: Interacción, Cognición, Autonomía y Acceso.

Ese marco es el que el Capítulo 4 desarrolla. Lo hace sobre la base que BCA acaba de establecer: sabemos qué teníamos antes, sabemos qué migra, sabemos qué permanece. Ahora podemos describir, con la calma que el cambio merece, la arquitectura del lado al que vamos.