Развилки архитектурных решений (пример)

Я выдумал этот простенький пример, чтоб лучше проиллюстрировать заметку Развилки архитектурных решений . Набросал текст и сохранил его в комментариях к исходному сообщению. Сейчас решил поднять его из комментов в отдельную запись.

Solution architect Семён получил новую задачку: расширить функционал простенького сервиса обработки заявок. Ничем не примечательный сервис предоставляет HTTP API, с коллекцией request, в которую можно опубликовать заявку. Проведя пару проверок и обогатив заявку данными из внешних систем, сервис отправляет заявку в очередь сообщений. Семён недавно работает в компании и хотя, по его мнению, задачка довольно простая, решает посоветоваться с Enterprise architect-ом Евгением. Тем более, что на днях Евгений собрал всех solution-ов и рассказал им о записях архитектурных решений (architecture decision record). Теперь каждый архитектор должен не только набросать небольшой эскиз, но и выложить набор решений в виде adr-файлов в версионное хранилище.
К удивлению Семёна вечно занятый Евгений был на рабочем месте. Дорисовывая очередной слайд он бросил Семёну:
– Что у тебя?
– Доработка сервиса обработки заявок, – пробурчал Семён.
– И в чём вопрос? – поинтересовался Евгений.
– Оформляю архитектурные решения, хочу посоветоваться.

Евгений посмотрел эскиз, поморщился и выдал свой любимый вопрос:
– Альтернативы придумал?
– Дорабатываем существующий сервис – Семён слегка замешкался. – Или пишем новый.

В этот момент к разговору внезапно присоединились еще два участника. Проектный менеджер Пётр, курирующий все доработки внутренних приложений в рамках программы цифровизации административной и внтурихозяйственной деятельности и продуктовый менеджер Павел. Эти двое всегда ходили вместе и постоянно спорили между собой.
– Не надо нам ничего переписывать! – не здороваясь начал Пётр. – Всё должно было заработать уже вчера! Десятки заявок в день вручную приходится разгребать.
– Это потому, что Борис накосячил, – включился в разговор Павел. – Вручную разгребаются заявки, которые не обработались с первого раза.
– Ну вот и подвернулась возможность Борису реабилитироваться, – не сдавался Пётр.

Не дожидаясь, пока эти двое окончательно втянутся в бесконечный спор, Евгений встал, подошёл к доске и рисуя квадратики принялся увещевать участников импровизированного совещания:
– У нас несколько вариантов реализации этой задачки. Самый простой, но не самый правильный состоит в том, чтоб сделать ещё одну очередь и написать новый компонент, который будет перекладывать сообщения из старой очереди в новую. Попутно он будет трансформировать ваши заявки.
– Не вариант! – прервал Евгения Павел. – Половина заявок в этот момент уже лежит в очереди ошибочных сообщений и разгребать их будет не ваш волшебный сервис, а рота сотрудников службы поддержи.
Павел покосился на Петра, ища у него поддержки. Вопреки традиции постоянно спорить с Павлом Пётр закивал.
– Хорошо! Вариант номер два, – не отступал Евгений. – Подменяем существующий сервис новым, с таким же интерфейсом, что и сервиса Бориса. Он будет обрабатывать все заявки. Некоторые сразу сбрасывать в очередь, а часть отдавать в старый сервис.

Павел одобрительно закивал:
– Меньшую часть, я надеюсь, – удовлетворенно заметил Павел.
– Как получится, – включился в разговор Семён, про которого все уже, казалось, забыли. – Этот вариант не решит никаких проблем, только создаст новые!
Участники разговора повернулись к Семёну, стали разглядывать его с некоторой нехорошей настороженностью. Семён, уже с меньшей уверенностью, продолжал:
– Наша проблема в чём? Вот в этих синхронных вызовах внешних апи, – Семён указал рукой в правую часть доски, на которой могли бы быть нарисованы интерфейсы внешних систем, используемые для обогащения заявок дополнительными данными. – Сервис Бориса почему тормозит? Потому, что внешние системы ему медленно отвечают. Что новый сервис, что старый, работать всё будет так же плохо! Только дополнительный синхронный вызов воткнем, а по существу ничего не изменится.
Настороженность во взглядах собеседников стала преобразовываться в легкую злобу. Особенно у Евгения, предложившего, как ему казалось, такой отличный вариант.
– Ну и что с этим делать? – первым взял себя в руки Павел.
– Реплики данных из внешних систем, – предположил Семён
– И кто за это заплатит? – поинтересовался Пётр.
…
В общем, в этот день коллеги так ни о чем и не договорились. Евгений отправил Семёна писать adr. Семён быстренько накатал файлик с двумя вариантами: доработать существующий сервис или написать новый. А проблема осталась ждать своего решения