Elegir microservicios según los cambios independientes

¿Qué cambio debe poder hacerse de forma independiente?

Distribuir una aplicación entre servicios no crea por sí solo evolución independiente. Si las mismas personas deben cambiar y desplegar todos los servicios juntos por cada regla de precios, la coordinación sigue existiendo. Se añaden llamadas de red y tareas de operación.

Microsoft describe despliegue independiente y responsabilidad propia de los datos como características importantes. Proponemos partir de un cambio concreto: ¿qué área de negocio debe asumirlo sin adaptar simultáneamente las demás?

Ejemplo: presupuestos y pedidos siguen juntos por ahora

Este producto y su funcionamiento son ficticios. Un equipo mantiene presupuestos, pedidos e informes. Las reglas de precios cambian juntas en presupuestos y pedidos. Los formatos de informe tienen otras necesidades de cambio.

En este plan, la aplicación sigue primero como monolito modular: límites internos y despliegue común. Spring Modulith ilustra la diferencia entre interfaz pública de un módulo e implementación interna. Describir esa separación es útil sin elegir esa herramienta concreta.

Incluya la operación en la decisión

Un servicio de informes separado tendría que gestionar fallos de su fuente de datos. Alguien debería responsabilizarse de despliegue, supervisión y análisis de incidentes. El equipo también necesita reglas para que versiones antiguas y nuevas de la interfaz convivan durante la transición. Un proceso separado no basta.

Registre el motivo de una separación posterior: por ejemplo, necesidad real de despliegue independiente o carga que requiere otro tratamiento. Revise el acoplamiento, el acceso a datos y el esfuerzo operativo. Los módulos desplegados juntos también pueden estar bien estructurados. Un servicio bien delimitado puede justificarse antes de dividir el resto. El número de servicios no mide la calidad de esta decisión.

Fuentes

• Microsoft: Microservices architecture

• Spring Modulith: Fundamentals