← dev-notes
MICROSERVICIOS · INFOGRAFÍA 1 / 5

Límites, contratos
y gobernanza

Conway, bounded contexts (DDD) y calidad en el borde entre equipos. Complementa la profundidad de dominio en DDD en dev-notes.

MS · 01
Conway's Law Bounded context Contratos Trade-offs
01 Definición operativa
🧱
NO ES SOLO TAMAÑO DEL DEPLOYABLE
Microservicio = servicio alineado con un límite de negocio, con datos y ciclo de vida propios.
Se despliega de forma independiente, habla con otros por contratos de red (HTTP/gRPC/eventos) y no comparte base de datos con otros equipos en el modelo feliz. La complejidad se mueve del código al ensamble distribuido: observabilidad, consistencia eventual, versionado y cultura de equipos.
02 Conway's Law — la organización gana
Los límites del software copian la comunicación de los equipos
EQUIPO A
Pedidos & catálogo
CONTRATO
API / eventos versionados
EQUIPO B
Pagos & riesgo

Si el organigrama no coincide con los límites del dominio, tendrás fricción: “nuestro” microservicio termina siendo propiedad compartida y sin dueño claro. Inverse Conway maneuver: reorganizar equipos para empujar la arquitectura deseada.

03 Descomposición — bounded contexts (DDD)
LÍMITE
Un contexto = un modelo coherente
Ubiquitous LanguageAgregados
Cada servicio (idealmente) custodia un bounded context: su propio significado de “Cliente”, “Pedido”, etc. Lo que en otro contexto se llama igual puede ser otro concepto — se relacionan por integración explícita, no por tablas compartidas.
ANTIPATRÓN
Microservicio por capa técnica
UI / API / DBAcoplamiento fuerte
Partir “capa de acceso a datos” vs “capa de negocio” en servicios distintos suele generar cascadas de llamadas y ownership difuso. La descomposición feliz sigue dominios, no carpetas de proyecto.
04 Contratos y gobernanza entre equipos
📜
GOBERNANZA
Lo que fija calidad en el borde
OpenAPI / protoSemver del contratoSLI/SLO entre equipos
Publicar contrato (REST/gRPC/async schema), reglas de compatibilidad hacia atrás, ventanas de deprecación y canales de incidentes. Sin esto, cada deploy es una negociación ad hoc.
Pregunta en diseño: ¿quién es el dueño del contrato, cómo se versiona y qué pasa si un consumidor no migra a tiempo?
La “API First” no es documentación bonita: es el orden en que se define el sistema distribuido.
05 Monolito vs microservicios — trade-offs honestos
Dimensión
Monolito modular
Microservicios maduros
Complejidad inicial
Baja — un árbol de deploy, transacciones locales.
Alta — red, observabilidad, contratos, equipos.
Escala de equipos
Limitada — merges y ownership compiten.
Equipos autónomos si los límites son reales.
Consistencia
ACID dentro del proceso único (simplifica).
Eventual entre servicios — diseño explícito (véase sistemas distribuidos).
Cuándo plantearlo
Producto joven, dominio aún fluido.
Varios equipos, límites claros, plataforma lista.
Siguiente infografía
Los límites anteriores obligan a dueño del dato por servicio. Sigue en Datos distribuidos — database per service.