Spring State Machine

Недавно в нашем проекте появился новый микросервис. После начальной конфигурации и добавления минимального функционала он стал быстро обрастать бизнес-логикой -- создание продуктов, процессинг, перевод продукта из статуса в статус. В других наших микросервисах за это отвечает непосредственно бизнес-логика, но для нового сервиса аналитики предложили внедрить Spring State Machine.

Из определения SSM:
"Spring State Machine — это фреймворк для Spring-приложений, который реализует концепцию расширенного конечного автомата. Он позволяет декларативно определять состояния и переходы между ними, поддерживает иерархические и параллельные состояния, а также действия, условия перехода и события."

Это показалось хорошей идеей: возможность формализовать логику переходов между состояниями и уйти от запутанных переходов в коде с многочисленными if...else if конструкциями. Задача ушла в разработку.

Когда я просматривала ее на code review, меня заинтересовал один технический момент. Пока я ресерчила этот вопрос, я внезапно наткнулась на сообщение о том, что Spring прекращает поддержку open source версии Spring State Machine с июня 2026! А значит через год библиотека SSM устареет и обновлений не предвидится. Но политика нашей компании обязывает обновлять версии, в которых обнаружены уязвимости. А поскольку обновлений нет, то библиотеку пришлось бы убирать из проекта.

А сколько кода было бы написано через год поверх SSM в нашем сервисе? И как больно было бы выпиливать его? Конечно, было принято решение не внедрять SSM в проект.

Для меня было сюрпризом, что Spring просто прекратил поддержку одного из своих проектов. Анонс о прекращении был 21 апреля 2025 года : https://spring.io/blog/2025/04/21/spring-cloud-data-flow-commercial
И что мне показалось интересно, я встретила свежие статьи в рунете с разбором SSM, которые даже не упоминали факт, что через год библиотека станет неактуальной. Похоже, стоит перепроверять на Github активность по каждой third-party библиотеке, которая добавляется в проект.

#рабочее