История изменений

Ну, как типовых… Ты же устаревшие решения предложил, которые давно никому не понятны. Так то почти оригинальные.

Устаревшие технологии это Java EE 7 на Wildfly application server, восьмая джава. Проект уже переписывали с нуля лет 6 назад, не такой он и старый. Работает стабильно, магии почти нет, все нюансы задокументированы и понятны не только основной команде, что пилят проект, но и основным клиентам.

Кстати, можешь в общих чертах описать основные принципы-технологии, которые использовал ты в противовес новому архитектору? Я могу предположить что-то вроде микросервисов.

Старый проект прост как тапки:

• первый слой принимает SOAP/XML на вход, делает оркестрацию запроса, ходит в базу за конфигами и далее шлёт пачку последовательных запросов во второй слой. То есть в одном XML может быть множество сервисов, которые надо активировать через второй слой
• второй слой принимает REST запросы, список API исчисляется парой сотен. Каждый сервис атомарный (за парой исключений) и для активации сервиса посылается запрос уже в третий слой. Этим вторым слоем тоже могут пользоваться заказчики.
• третий слой это тупо интеграционный сервис с железяками от поставщиков, там и SOAP’ы, и REST и SSH и прочее.

Первый слой нужен для поддержки обратной совместимости для старых клиентов, второй для более модных-молодёжных. Всё это дело решили заменить, так как даже первый слой недостаточно умён, чтобы как какой-нибудь Terraform разрулить зависимости и правильно активировать сервисы, заказчик должен понимать что активировать и как.

Так вот, организация решила запустить новый проект по переписыванию этой системы с использованием Кафки (компании очень хочется Кафку везде впендюрить), а также сделать так, чтобы клиент используя OpenAPI указал необходимые сервисы в запросе и всё магическим способом произошло. Так вот я расписал архитектуру нового проекта и полгода с командой пилил, а как ушёл, новый архитектор ни на один вопрос не ответил. Слился отговорками и пытается повесить всё на разработчиков. А разработчики не видят полную картину, они не могут сами вывезти большой проект с кучей интеграций.

Я не считаю себя гениальным архитектором, команда сама мне пишет теперь, что если раньше я работал на команду, в приоритете было обеспечить их понятными задачами, то новый архитектор ничем не помогает по факту, одни совещания с результатом посовещаться ещё. Люди бывает целый спринт пинают МПХ, потому что не понятно, что делать и как.

Ну, как типовых… Ты же устаревшие решения предложил, которые давно никому не понятны. Так то почти оригинальные.

Устаревшие технологии это Java EE 7 на Wildfly application server, восьмая джава. Проект уже переписывали с нуля лет 6 назад, не такой он и старый. Работает стабильно, магии почти нет, все нюансы задокументированы и понятны не только основной команде, что пилят проект, но и основным клиентам.

Кстати, можешь в общих чертах описать основные принципы-технологии, которые использовал ты в противовес новому архитектору? Я могу предположить что-то вроде микросервисов.

Старый проект прост как тапки:

• первый слой принимает SOAP/XML на вход, делает оркестрацию запроса, ходит в базу за конфигами и далее шлёт пачку последовательных запросов во второй слой. То есть в одном XML может быть множество сервисов, которые надо активировать через второй слой
• второй слой принимает REST запросы, список API исчисляется парой сотен. Каждый сервис атомарный (за парой исключений) и для активации сервиса посылается запрос уже в третий слой. Этим вторым слоем тоже могут пользоваться заказчики.
• третий слой это тупо интеграционный сервис с железяками от поставщиков, там и SOAP’ы, и REST и SSH и прочее.

Первый слой нужен для поддержки обратной совместимости для старых клиентов, второй для более модных-молодёжных. Всё это дело решили заменить, так как даже первый слой недостаточно умён, чтобы как какой-нибудь Terraform разрулить зависимости и правильно активировать сервисы, заказчик должен понимать что активировать и как.

Так вот, организация решила запустить новый проект по переписыванию этой системы с использованием Кафки (компании очень хочется Кафку везде впендюрить), а также сделать так, чтобы клиент используя OpenAPI указал необходимые сервисы в запросе и всё магическим способом произошло. Так вот я расписал архитектуру нового проекта и полгода с командой пилил, а как ушёл, новый архитектор ни на один вопрос не ответил. Слился отговорками и пытается повесить всё на разработчиков. А разработчики не видят полную картину, они не могут сами вывезти большой проект с кучей интеграций.

Я не считаю себя гениальным архитектором, команда сама мне пишет теперь, что если раньше я работал на команду, в приоритете было обеспечить их понятными задачами, то новый архитектор ничем не помогает по факту, одни совещания с результатом посовещаться ещё. Люди бывает целый спринт пинают МАХ, потому что не понятно, что делать и как.