Cuando un sistema empieza a sentirse difícil de cambiar, es tentador atribuir el problema a su forma de despliegue. La discusión suele saltar pronto a una alternativa conocida: dividirlo en servicios. Sin embargo, antes de elegir una topología conviene precisar qué partes del dominio tienen responsabilidades distintas, qué decisiones cambian juntas y quién puede mantener cada límite. El nombre de una arquitectura no explica por sí mismo dónde poner una frontera ni qué costo operativo tendrá sostenerla.
Separar el problema del nombre de la arquitectura
Un monolito describe una forma de empaquetar o ejecutar una aplicación; no obliga a que todas sus funciones estén mezcladas. Se puede organizar un despliegue único alrededor de módulos con interfaces explícitas, dependencias controladas y propiedad clara de los datos. La modularidad es una propiedad del diseño interno, no una cantidad de procesos en producción.
La arquitectura de microservicios, por su parte, suele describir una aplicación como un conjunto de servicios que se despliegan de manera independiente y colaboran a través de mecanismos de comunicación. Martin Fowler y James Lewis señalan que no existe una definición precisa única, aunque identifican características compartidas, entre ellas organizar servicios alrededor de capacidades de negocio. Esa descripción ayuda a comparar opciones, pero no selecciona automáticamente el diseño apropiado (Microservices).
Descubrir límites desde el dominio
El análisis de dominio comienza por entender capacidades, procesos y conceptos del negocio antes de asignar componentes. La guía de Microsoft sobre análisis de dominio advierte que delimitar servicios no se obtiene mediante una regla mecánica: requiere examinar el dominio y las necesidades de la solución (Domain analysis for microservices). La advertencia importa incluso si el resultado final es un monolito. Los módulos también necesitan límites que expresen qué responsabilidad contienen y cómo colaboran.
Como criterio de trabajo, escriba una lista corta de capacidades y para cada una anote sus entradas, decisiones propias, datos que modifica y dependencias. Si dos áreas cambian coordinadamente para completar una misma regla, separar el código por nombres de carpetas no crea autonomía real. Si una capacidad tiene vocabulario, reglas y ritmo de cambio distinguibles, puede ser candidata a módulo explícito. Esta lista es una herramienta de conversación, no una técnica que demuestre de antemano la frontera correcta.
Ejemplo hipotético: imagine una aplicación que administra solicitudes y notificaciones. Si modificar el estado de una solicitud requiere una regla que también determina qué aviso se envía, el equipo debería documentar esa coordinación antes de dividir procesos. Puede conservar la regla en un módulo compartido mientras aprende dónde está la responsabilidad. El ejemplo no describe una organización ni prescribe una estructura específica.
Qué cambia cuando se distribuye
Separar un módulo en un proceso independiente introduce una interfaz remota y una operación que debe mantenerse. El artículo de Fowler y Lewis describe servicios con procesos propios y mecanismos ligeros de comunicación. De esa descripción se desprenden preguntas de diseño: qué ocurre cuando una llamada no responde, qué datos se comparten, quién detecta una incompatibilidad y cómo se observa una operación que atraviesa componentes.
Una frontera distribuida no elimina el acoplamiento: lo vuelve visible en contratos, eventos, datos y coordinación entre despliegues. También cambia la manera de diagnosticar fallos. Un módulo llamado dentro del mismo proceso y un servicio remoto no comparten las mismas condiciones de ejecución, aunque ambos representen una capacidad de negocio. Por ello, “separar para escalar” o “dividir para ordenar” son explicaciones incompletas si no identifican la restricción concreta que se quiere atender.
Martin Fowler propone “Monolith First” como una consideración para proyectos nuevos: aprender el dominio dentro de un sistema cohesivo puede ayudar a evitar comprometerse demasiado pronto con límites equivocados. El mismo texto reconoce el contexto de la propuesta y no afirma que toda aplicación deba permanecer monolítica (Monolith First). Trátese como argumento para evaluar incertidumbre, no como ley ni mandato.
Comparar opciones con preguntas verificables
Como criterio de trabajo, documente la opción actual y al menos una alternativa en los mismos términos:
- ¿Qué capacidad o regla debería poder cambiar sin coordinarse con otras?
- ¿Qué datos son responsabilidad de cada módulo y qué invariantes deben preservarse?
- ¿Qué interfaz necesitaría existir entre límites y quién la mantiene?
- ¿Qué prácticas de operación, observabilidad y respuesta a fallos están disponibles?
- ¿La dificultad observada nace de una frontera confusa, de un proceso de trabajo o de una restricción de despliegue?
Estas preguntas no producen una puntuación universal. Sí hacen revisables los supuestos. Si no hay evidencia de que distribuir una parte resuelva un problema determinado, conservar un módulo bien definido puede ser una decisión deliberada y reversible. Si aparecen necesidades separadas de despliegue, propiedad o evolución, el equipo puede estudiar una extracción acotada y revisar los contratos en vez de planear una división total.
Registrar la decisión y sus límites
Una decisión arquitectónica útil explica qué contexto se conoce, qué se desconoce y qué señal motivaría revisarla. Registre los límites elegidos, el sentido de las dependencias y los datos cuya consistencia importa. También documente quién puede cambiar cada componente y qué operaciones adicionales aparecerían si se distribuye. Evite declarar que una alternativa “escala mejor” sin especificar la dimensión medida y las condiciones: carga, organización, infraestructura y forma de operar pueden cambiar el resultado.
Si los límites siguen inciertos, posponer una separación no equivale a ignorar el problema. Puede ser una decisión de aprendizaje que mantiene pocas piezas y hace explícita la pregunta pendiente. Del mismo modo, adoptar servicios distribuidos puede tener sentido cuando existe una necesidad concreta y el equipo puede asumir sus interfaces y operación. El criterio está en la correspondencia entre límites del dominio, capacidades del equipo y restricciones observadas, no en la popularidad de una etiqueta.
Qué no cubre este artículo
Esta nota no prescribe una arquitectura para una organización ni compara plataformas, proveedores o costos. Tampoco sustituye un análisis de dominio, una revisión de consistencia de datos o una evaluación operativa de un sistema concreto. Las fuentes describen conceptos y argumentos generales; la elección requiere evidencia y revisión del contexto propio.
