La opinión de Pollito acerca del desarrollo en Spring Boot 1: Desarrollo impulsado por contratos
Posted on October 2, 2024 • 3 minutes • 607 words • Other languages: English
Un poco de contexto
Esta es la primer parte de la serie de blogs Spring Boot Development .
- El objetivo de esta serie es ser una demostración de cómo consumir y crear una API siguiendo los principios del Desarrollo impulsado por contratos .
- El objetivo de este blog es entender esos principios.
Desarrollo impulsado por contratos
En el artículo de Wikipedia Design by contract wikipedia article , podemos encontrar la siguiente afirmación:
[…] software designers should define formal, precise and verifiable interface specifications for software components, which extend the ordinary definition of abstract data types with preconditions, postconditions and invariants.
A partir de ahí, hice mi propia adaptación de la filosofía de desarrollo impulsado por contratos para la arquitectura de microservicios:
Los microservicios deben cumplir con un contrato, que define entradas, salidas y errores.
Entonces ¿qué es un contrato?
Contrato
Conjunto de aserciones que contienen la siguiente información:
- Valores de entrada válidos y su significado.
- Valores de retorno válidos y su significado.
- Valores de error que pueden ocurrir y su significado.
En un contrato hay dos partes:
- Consumidor: proporciona los valores de entrada y espera el retorno.
- Proveedor: espera los valores de entrada y proporciona el retorno.
No existen reglas que establezcan con cuántos contratos cumple un microservicio ni qué funciones desempeña en ellos. Pero aquí están mis recomendaciones personales mantenernos lo más cerca posible de la definición original:
- Un microservicio cumple al menos con un contrato y desempeña el rol de proveedor.
- Un microservicio puede desempeñar el rol de consumidor en cero, uno o muchos contratos.
- Un microservicio puede desempeñar el rol de consumidor en cero, uno o muchos contratos.
Veamos cada uno con más detalle.
- Un microservicio cumple al menos con un contrato, desempeñando el rol de proveedor.
Para un microservicio que sigue estrictamente las prácticas de desarrollo impulsado por contratos, sin cumplir con esta regla, no tiene forma de ser invocado desde fuentes externas.
Tal vez haya situaciones en las que sea necesario tener un microservicio en ejecución, pero no poder invocarlo, pero al momento de escribir esto, no se me ocurre ninguna situación.
- Un microservicio puede desempeñar el rol de consumidor en cero, uno o muchos contratos.
Este punto no se trata de desarrollo impulsado por contratos, sino más bien de la filosofía adecuada de los microservicios. Un microservicio está pensado para ocuparse de una sola cosa y hacerla bien. Para lograrlo, tiene sentido que el microservicio sea un proveedor solo una vez, proporcionando los puntos finales para interactuar con la única cosa que hace bien.
Puede haber excepciones totalmente válidas a esto. Un ejemplo claro es un microservicio que expone un punto final actuator . Ahora tienes un microservicio que hace dos cosas, su función principal y expone una llamada de comprobación de estado. Y eso está totalmente bien.
- Un microservicio puede desempeñar el rol de consumidor en cero, uno o muchos contratos.
Conclusión
- Los microservicios deben cumplir con un contrato, que define entradas, salidas y errores.
- Un contrato es un conjunto de aserciones que contienen la siguiente información:
- Valores de entrada válidos y su significado.
- Valores de retorno válidos y su significado.
- Valores de error que pueden ocurrir y su significado.
- En un contrato hay dos partes:
- Consumidor: proporciona los valores de entrada y espera el retorno.
- Proveedor: espera los valores de entrada y proporciona el retorno.
- Un microservicio cumple al menos con un contrato, desempeñando el rol de proveedor.
- Un microservicio puede desempeñar el rol de consumidor en cero, uno o muchos contratos.
Siguiente lectura
La opinión de Pollito acerca del desarrollo en Spring Boot 2: Mejores prácticas