Dentro del paradigma de diseño de orientación al servicio , la refactorización de servicios es un patrón de diseño , que se aplica a un servicio existente [1] para que la lógica del servicio o su implementación se pueda cambiar sin afectar a los consumidores del servicio.
Es bastante natural que un servicio sufra cambios debido a varias razones. El cambio podría ser necesario porque la implementación subyacente, por ejemplo, bases de datos, sistemas heredados , etc., debe actualizarse o simplemente porque la lógica del servicio original no estaba haciendo un uso eficiente de la memoria. En otros casos, el cambio podría iniciarse desde los propios consumidores del servicio, por ejemplo, con un uso concurrente limitado, el servicio se desempeña como se indica en su SLA , sin embargo, con un aumento en su uso concurrente, el servicio no puede cumplir con su SLA, por lo tanto, el el servicio debe responder a las crecientes demandas de rendimiento de sus consumidores de servicios. [2]
Esta situación debe tratarse de manera que el servicio se actualice sin afectar a sus consumidores que ya han formado dependencias del servicio. Aunque se podría argumentar que responder a cualquiera de los requisitos antes mencionados no debería ser problemático siempre que el servicio cumpla con su contrato, sin embargo, aquí no solo nos preocupa la exactitud del resultado relacionado con la ejecución de las capacidades del servicio [3] pero también con el comportamiento y la confiabilidad del servicio. Para abordar estos problemas, el patrón de diseño de Refactorización de servicios proporciona una estrategia que se esfuerza por garantizar que un servicio pueda evolucionar sin afectar negativamente a sus consumidores. [4]
La aplicación de este patrón de diseño aboga por el uso de técnicas tradicionales de refactorización de software . El enfoque está en refactorizar el servicio en pasos más pequeños para que el impacto de cada paso sea lo suficientemente pequeño como para revertirlo en caso de que tal cambio afecte negativamente a los consumidores del servicio. En segundo lugar, para garantizar que el contrato de servicio no se vea afectado por cambios en la lógica o la implementación, el contrato de servicio debe desacoplarse tanto como sea posible. [5] Esto se puede hacer mediante la introducción de un componente de fachada [6] entre el contrato de servicio y la lógica del servicio. Sin embargo, esto solo es posible si el contrato de servicio está físicamente desacoplado de su implementación en primer lugar, lo que podría lograrse mediante la aplicación del contrato desacoplado.[7] patrón de diseño. Esto podría fortalecerse aún más mediante la aplicación delpatrón de diseño deContract Centralization [8] que aboga por establecer el contrato de servicio como el único punto de entrada oficial al servicio.
Por otro lado, para aislar la lógica del servicio de los efectos negativos de los cambios en la implementación del servicio, se podría volver a aplicar el patrón de diseño de la fachada del servicio para introducir otro componente de la fachada entre la implementación del servicio y la lógica del servicio. La aplicación del principio de abstracción del servicio puede ayudar aún más a reducir las posibilidades de cualquier efecto perjudicial causado por la aplicación de este patrón de diseño. [9]
La aplicación del patrón de diseño de Refactorización de servicios requiere pruebas exhaustivas para garantizar un servicio confiable y probado, aunque ineficiente, lleva el mismo nivel de estabilidad de comportamiento y confiabilidad. Esto podría aumentar los costos del proyecto y requeriría procedimientos adicionales de garantía de calidad y una gobernanza estricta.