Service-Based Architecture
Convención y variación terminológica
Service-Based Architecture no tiene una definición universal completamente estable. Puede usarse informalmente para cualquier arquitectura con servicios o, en literatura específica, para un perfil de servicios de dominio relativamente amplios. El Atlas adopta este segundo sentido y conserva la diferencia respecto del uso genérico.
Aquí describe un número reducido de servicios relativamente coarse-grained, desplegables de forma independiente, orientados normalmente a dominios o capacidades amplias. Reducido y coarse-grained son relativos al sistema y al problema, no límites numéricos normativos.
Richards y Ford describen servicios remotos separados y una variante habitual con base de datos compartida. Fundamentals of Software Architecture, capítulo 13. El Atlas no convierte el rango de cantidad de servicios presentado por esos autores en una definición ni exige esa topología de datos para todos los casos.
architecture-profile permite analizar decisiones combinadas sin reducir el perfil a «tener servicios». architecture-pattern-terminology explica por qué distintas fuentes pueden llamar style o architecture a aproximaciones relacionadas.
Servicios amplios y límites deliberados
Un servicio reúne una porción significativa de comportamiento: por ejemplo, operaciones comerciales, facturación o gestión de recursos. Puede contener varios módulos internos. La frontera busca conservar cohesión y reducir interacciones remotas para las operaciones frecuentes.
No equivale a desplegar por separado cada capa técnica ni a convertir cada entidad en una API. La elección del límite requiere observar qué cambios ocurren juntos, qué invariantes comparten datos y qué responsabilidad necesita un contrato propio.
La granularidad más amplia puede mantener trabajo transaccional dentro de un servicio y reducir conversaciones entre unidades. También puede reunir capacidades con cargas o ritmos de cambio diferentes. El beneficio y el costo nacen del mismo agrupamiento, no de la cantidad de repositorios.
Ejes de análisis
| Eje | Tendencia y pregunta relevante |
|---|---|
| Decomposition | Capacidades amplias agrupadas en pocos servicios relativos al dominio. |
| Dependency Structure | Contratos entre servicios; estructura interna todavía por decidir. |
| Communication | Llamadas de red o mensajes entre unidades; llamadas locales dentro de ellas. |
| Coordination | Operaciones locales más amplias y coordinación distribuida cuando cruzan servicios. |
| Data Ownership | Puede compartir infraestructura o esquema; hay que precisar autoridad y acoplamiento. |
| Isolation | Procesos separados pueden contener algunos fallos; datos y recursos comunes limitan aislamiento. |
| Tenancy | Decisión adicional de acceso y partición, no consecuencia de la granularidad. |
| Deployment | Unidades separadas; independencia efectiva depende de compatibilidad y datos. |
| Execution Model | Servicios persistentes, tareas y consumidores según la solución. |
| Scaling | Capacidad por servicio amplio; componentes internos pueden crecer conjuntamente. |
La autonomía del artefacto no demuestra autonomía de cambio. Dos paquetes desplegables pueden requerir una misma ventana de release si comparten un contrato incompatible o una migración transversal.
Comunicación y coordinación
Una llamada entre servicios necesita presupuestos de tiempo, contrato de errores y una política de recuperación. La menor cantidad de límites no elimina la posibilidad de fallo parcial. timeout e idempotency permiten examinar decisiones específicas sin convertir esta página en un resumen de distribución.
Conservar una operación dentro de un servicio puede simplificar sus invariantes. Cuando cruza unidades, hay que decidir qué resultado parcial es aceptable y cómo completarlo o recuperarlo. saga-pattern describe una opción para ciertos procesos; no es una obligación de todo perfil con servicios.
Las comunicaciones deben ajustarse al alcance: numerosas llamadas pequeñas pueden producir dependencia temporal y latencia aunque existan pocos servicios. Los contratos también pueden acoplar releases si filtran estructuras internas o exigen actualizar todos los consumidores a la vez.
Datos compartidos: opción con consecuencias
Una base de datos compartida puede facilitar consultas o consistencia sobre información común y reducir trabajo inicial. También introduce dependencias de esquema, acceso y capacidad. No debe presentarse como una ventaja sin costo ni como una imposibilidad técnica.
Hay que distinguir infraestructura compartida, ownership lógico y permiso para modificar los mismos datos. Usar un servidor común no exige compartir todas las tablas; compartir una tabla tampoco aclara quién protege sus invariantes. Esa decisión debe describirse por separado.
Si dos servicios escriben las mismas estructuras, una migración podría necesitar releases coordinados y un fallo del almacenamiento afectarlos conjuntamente. Si se separan responsabilidades y contratos, parte de ese acoplamiento puede reducirse, aunque permanezcan recursos físicos comunes.
Service-Based frente a Microservices
microservices enfatiza autonomía de evolución, ownership y despliegue alrededor de responsabilidades delimitadas. Service-Based prioriza aquí agrupamientos más amplios y un compromiso pragmático entre separación operativa y coordinación interna. Las descripciones pueden superponerse; no existe un umbral de líneas, endpoints o servicios que resuelva toda clasificación.
Menos servicios pueden significar menos contratos y entornos por administrar, pero no garantizan menor complejidad: una topología con dependencias densas o datos muy acoplados puede ser difícil de operar. Más granularidad puede ayudar a una capacidad concreta y aumentar interacciones para una operación frecuente.
Fowler menciona comenzar con servicios amplios como una posibilidad para aprender límites, sin convertirla en la única ruta. Monolith First. El Atlas admite Service-Based como elección duradera, no como una etapa obligatoria entre modular-monolith y Microservices.
Delivery, equipos y costo operativo
Un equipo puede asumir un servicio amplio y mantener un ciclo de entrega propio cuando sus contratos lo permiten. Otros cambios requerirán coordinación explícita. El ownership organizativo debe corresponder a responsabilidad real; repartir paquetes sin autoridad sobre sus datos conserva dependencia entre equipos.
Los tests locales cubren comportamiento interno; los tests de contrato y de integración deben comprobar expectativas entre unidades. La observabilidad necesita relacionar una operación de negocio con sus interacciones remotas y distinguir lentitud del servicio de problemas de una dependencia.
Los costos incluyen pipelines, configuración, versiones simultáneas, diagnóstico y mecanismos de recuperación. Reducir la cantidad de unidades puede contener parte de ese inventario. La diversidad tecnológica es posible, pero cada variante añade necesidades de operación y conocimiento.
Ejemplo de comparación situada
Supongamos una organización con gestión comercial y facturación, equipos que necesitan ritmos de entrega distintos y varias reglas que cambian juntas dentro de cada capacidad. Dos servicios amplios pueden preservar coordinación local en cada área y separar sus entregas.
Si el cálculo de una factura requiere leer representaciones privadas de la gestión comercial, la separación necesita revisar el contrato. Si ambas unidades escriben un esquema común, se debe explicitar quién decide cambios y cómo se mantienen versiones compatibles.
La decisión se contrasta con mantener módulos locales o separar más capacidades. El objetivo es resolver un problema concreto de delivery o responsabilidad, no demostrar un avance hacia una etiqueta.
Composición y límites de uso
Cada servicio puede organizarse mediante Layered, Hexagonal o Vertical Slice. Event-Driven Architecture puede participar en sus interacciones, y SOA puede aportar una perspectiva de integración entre capacidades. Esas decisiones no son alternativas necesariamente excluyentes.
Puede ser razonable cuando existen fronteras operativas útiles, el dominio favorece agrupamientos amplios y el equipo acepta costos distribuidos acotados. Se reconsidera cuando un servicio acumula cambios incompatibles, necesidades de scaling distintas o dependencias que impiden entregarlo por separado.
architectural-drivers y architectural-significance orientan esa evaluación. architecture-profiles compara el perfil con otras opciones mediante varios ejes, manteniendo visibles las variantes y la ambigüedad del término.