Comments 5
Self hosted... а зачем тогда логин на сайте?
Кликабельный маршрут выглядит полезным как поверхность проверки архитектуры. Остаётся риск: поток может быть внутренне согласованным, но уже устаревшим. Контракт изменился, а шаг всё ещё ведёт к прежней версии, поэтому визуальной дыры в маршруте нет.
Я бы связывал каждый переход не только с endpoint или каналом, но и с версией контракта, владельцем и проверяемым сценарием. Изменение OpenAPI или схемы события тогда должно помечать связанные потоки как требующие повторной проверки.
У вас такая инвалидация может происходить автоматически или актуальность маршрута пока остаётся ответственностью его автора?
Очень хорошая мысль. Я часто думаю насчет того, как вообще поддерживать актуальность связей, потоков, сервисов и вообще всего ландшафта. С одной стороны можно актуализацию проводить после релиза контракта, зашить в CI актуализацию документации, потоков, контрактов и связей.
С другой стороны хочется иметь набор версий каждой связанности и при изменении контрактов действительно подсвечивать валидацию определенного magic flow.
К единому мнению еще не пришел.
Я бы развёл эти механизмы. CI может зафиксировать изменение и пометить затронутые потоки как needs review. Версия нужна, чтобы сохранить основание прежнего решения и понять, что именно изменилось.
Но автоматически вернуть поток в статус «актуален» CI сможет только для технических инвариантов. Для бизнес-сценария всё равно нужен владелец, который подтвердит новую версию.
Тогда цепочка будет такой: изменение контракта → вычисление затронутых flow → автоматические проверки → явная приёмка владельцем. История версий и актуализация после релиза закрывают разные этапы.
Кто у вас мог бы принимать новую версию потока: его автор, команда сервиса или архитектор домена?
diff'ы magic flow у меня уже были заготовлены, так что статусы валидности и инвалидности потоков было не сложно сейчас добавить. Спасибо за хороший поинт. Я добавил валидацию потоков.
А насчет принятия новой версии потока - кажется тут зависит от слоя на котором он находится.
Если, допустим, поток находится на контекстном слое, то его может провалидировать и продуктовая часть команды, если же спускаемся до сервисов, то ответственный за интеграцию, или коллективно командами участвующих сервисов, но все-равно придется принять кому-то волевое решение, что оно работает так.
Но если уж есть архитектор, который прорабатывал данную интеграцию, то и он.
Все будет зависеть от слоя, на котором находится диаграмма, а так же практик принятых в отдельно взятых командах.
Хватит рисовать интеграции в Miro: я сделал архитектуру, которую можно прокликать