Tema 3
Una arquitectura distribuida solo funciona bien cuando sus límites representan algo real del negocio. Si los servicios se definen por comodidad técnica y no por capacidades entendibles, aparecen acoplamiento, duplicación, permisos ambiguos y sistemas difíciles de operar. Diseñar alrededor de dominios y bounded contexts evita ese problema.
En los temas anteriores vimos que no alcanza con decidir entre monolito y microservicios. También hace falta determinar cómo se parte el sistema. Esa partición no debería surgir de la estructura del equipo, de la tecnología elegida o de una división arbitraria de endpoints. Debería surgir del dominio que el sistema resuelve.
Cuando los límites arquitectónicos reflejan capacidades reales de negocio, el sistema resulta más fácil de entender, evolucionar y asegurar. Cada parte tiene un propósito más claro, un lenguaje más estable, reglas mejor definidas y un ownership más concreto. Cuando esos límites son artificiales, las dependencias se multiplican y la complejidad se esconde detrás de una falsa separación.
Este tema se enfoca en conceptos fundamentales para una descomposición sana: dominio, subdominio, bounded context y diseño orientado a capacidades. Aunque estas ideas suelen asociarse con Domain-Driven Design, aquí las vamos a tratar desde una perspectiva arquitectónica y de seguridad práctica.
El dominio es el problema de negocio que el sistema intenta resolver. No es la base de datos, ni la API, ni la interfaz de usuario. Es el conjunto de conceptos, procesos, reglas y decisiones que describen cómo funciona una parte del negocio.
Por ejemplo, en una plataforma de comercio electrónico pueden existir dominios como catálogo, inventario, pagos, envíos y atención al cliente. Cada uno responde a necesidades distintas, con reglas propias, vocabulario propio y criterios diferentes de seguridad y operación.
Dentro de un dominio mayor suelen existir subdominios. No todos tienen la misma importancia ni requieren el mismo nivel de inversión. Algunos son centrales para el valor del negocio y otros son de soporte.
| Tipo de subdominio | Qué representa | Impacto arquitectónico |
|---|---|---|
| Core | Capacidad diferenciadora del negocio | Requiere mayor cuidado en diseño, seguridad y evolución |
| Support | Capacidad necesaria pero no diferencial | Puede aceptar soluciones más estándar |
| Generic | Problema común en muchas organizaciones | Puede resolverse con plataformas o productos existentes |
Entender esta diferencia ayuda a no sobrediseñar todo por igual. También permite asignar mejor recursos de seguridad, observabilidad y gobierno sobre las capacidades que realmente sostienen el negocio.
Un bounded context es un límite dentro del cual un modelo de negocio tiene significado consistente. Dentro de ese límite, los términos, reglas y relaciones entre conceptos se entienden de una manera específica. Fuera de ese límite, los mismos términos pueden tener significados distintos.
Esto es importante porque muchos problemas de arquitectura aparecen cuando se fuerza un único modelo para todo el sistema. Un concepto como "cliente", "pedido" o "cuenta" puede significar algo distinto para facturación, logística o soporte. Pretender unificar todo sin matices suele generar acoplamiento y ambigüedad.
El lenguaje ubicuo es el vocabulario compartido entre negocio y tecnología para describir conceptos relevantes del dominio. No es un detalle teórico. Si los equipos no nombran igual las mismas cosas, los límites se vuelven borrosos y las interfaces entre componentes empiezan a romperse semánticamente.
En seguridad, esta claridad ayuda porque los controles no se aplican sobre objetos abstractos, sino sobre recursos y acciones con significado real.
Diseñar orientado a capacidades significa organizar el sistema alrededor de lo que el negocio necesita hacer, no alrededor de capas técnicas o tecnologías particulares. Una capacidad es una función relativamente estable que la organización debe poder ejecutar.
Ejemplos de capacidades pueden ser gestionar pagos, aprobar créditos, emitir facturas o rastrear envíos. Cada una de estas capacidades puede requerir reglas, datos, procesos y controles de acceso específicos. Cuando la arquitectura sigue esas capacidades, los límites resultan más duraderos y más comprensibles.
Una arquitectura con límites claros facilita la seguridad porque permite asociar permisos, datos, secretos, flujos de información y eventos auditables a responsabilidades específicas. Cuando todo está mezclado, la tendencia natural es asignar permisos amplios y generar accesos difíciles de justificar.
Cuando estas señales no aparecen, suele ser una advertencia de que el contexto todavía no está bien delimitado o que la partición se hizo demasiado rápido.
Estos síntomas suelen indicar que la arquitectura está copiando la complejidad del negocio sin modelarla correctamente.
Los bounded contexts no viven aislados. Necesitan relacionarse. La clave es que esas relaciones sean explícitas, limitadas y bien gobernadas. Si un contexto depende demasiado del modelo interno de otro, la separación pierde valor.
| Relación | Qué implica | Riesgo si se gestiona mal |
|---|---|---|
| Consumo por API | Un contexto expone una interfaz estable a otro | Acoplamiento fuerte si la API revela demasiado |
| Eventos | Un contexto publica hechos relevantes para otros | Propagación de semánticas ambiguas o datos excesivos |
| Datos compartidos | Varios contextos acceden al mismo repositorio | Pérdida de encapsulamiento y permisos confusos |
Un límite sano no termina en el diseño. También necesita ownership operativo. Tiene que quedar claro quién mantiene el servicio, quién responde incidentes, quién aprueba cambios sensibles y quién conoce el modelo funcional asociado.
Cuando varios equipos comparten una capacidad sin responsabilidad clara, aparecen huecos de seguridad: secretos sin dueño, accesos heredados, documentación inconsistente y baja capacidad de respuesta frente a un incidente.
No todos los contextos tienen la misma sensibilidad. Algunos manejan credenciales, tokens, datos financieros, información personal o decisiones críticas de negocio. Eso debería influir en cómo se define el límite y en qué controles adicionales se aplican.
Un error común es mapear cada endpoint o cada operación CRUD a un servicio distinto. Eso rara vez produce límites de negocio sólidos. Una capacidad agrupa reglas, decisiones, datos y procesos; no es simplemente un verbo sobre una tabla o un recurso HTTP.
Cuando se confunden capacidades con endpoints, proliferan servicios demasiado pequeños, de bajo valor y alto costo operativo. Además, la seguridad se vuelve más compleja porque se multiplican identidades y contratos sin una justificación funcional clara.
Imaginemos una plataforma de comercio electrónico. A primera vista podría parecer razonable crear servicios para usuarios, pedidos, pagos, productos y stock. Pero una mirada más profunda puede mostrar bounded contexts distintos.
Aunque todos usan el concepto de producto o pedido, no necesariamente lo entienden igual ni deberían compartir el mismo modelo interno.
No se trata de llegar a un modelo perfecto desde el inicio. Se trata de hacer explícitas las hipótesis de diseño y refinar los límites a medida que el conocimiento del dominio mejora.
Una arquitectura segura no se apoya solo en firewalls, gateways o cifrado. También depende de que el sistema esté dividido según capacidades y contextos entendibles. Cuando los límites son correctos, la arquitectura gana claridad, los permisos se vuelven más precisos y la operación responde mejor ante errores o incidentes.
En el próximo tema trabajaremos threat modeling para sistemas distribuidos y veremos cómo identificar amenazas, activos, actores y superficies de ataque antes de implementar controles.