diff'ы magic flow у меня уже были заготовлены, так что статусы валидности и инвалидности потоков было не сложно сейчас добавить. Спасибо за хороший поинт. Я добавил валидацию потоков.
А насчет принятия новой версии потока - кажется тут зависит от слоя на котором он находится. Если, допустим, поток находится на контекстном слое, то его может провалидировать и продуктовая часть команды, если же спускаемся до сервисов, то ответственный за интеграцию, или коллективно командами участвующих сервисов, но все-равно придется принять кому-то волевое решение, что оно работает так. Но если уж есть архитектор, который прорабатывал данную интеграцию, то и он. Все будет зависеть от слоя, на котором находится диаграмма, а так же практик принятых в отдельно взятых командах.
Очень хорошая мысль. Я часто думаю насчет того, как вообще поддерживать актуальность связей, потоков, сервисов и вообще всего ландшафта. С одной стороны можно актуализацию проводить после релиза контракта, зашить в CI актуализацию документации, потоков, контрактов и связей. С другой стороны хочется иметь набор версий каждой связанности и при изменении контрактов действительно подсвечивать валидацию определенного magic flow. К единому мнению еще не пришел.
C4 всё же больше про послойное описание архитектуры, чем непосредственно про инфраструктуру. Но если смотреть на жизненный цикл каждого элемента, неизбежно возникает вопрос: как поддерживать всю эту документацию в актуальном состоянии?
С одной стороны, хочется уже на старте иметь понятный и полный набор моделей, связей и структур. С другой — важно, чтобы это «безобразие» не устаревало через несколько месяцев.
С первой частью обычно всё относительно понятно. Со второй часто возникают проблемы:
Нет централизованного процесса поддержки документации. Как ни унифицируй подходы, со временем команды всё равно начинают использовать инструменты и форматы, которые удобнее именно им.
Разработчикам и аналитикам естественно держать документацию рядом с кодом, в репозитории, и обновлять её через привычный процесс review и merge request’ов.
Не определён источник истины. Что считать реальностью: документацию, где были зафиксированы договорённости, или фактическую реализацию сервиса?
Для себя я пришёл к тому, что источником истины должны быть именно зафиксированные договорённости. Желательно, чтобы документация была трассируема до требований, реализации и тестов — и обратно. Тогда второй и третий пункты во многом решаются сами собой: документация становится частью инженерного процесса, а не побочным артефактом.
Кроме того, при современных AI-подходах документация может быть не только описанием уже реализованной системы. На её основе можно генерировать контракты, интерфейсы, каркасы сервисов и часть бизнес-логики.
Кстати, в моем сервисе для авторизованных пользователей доступен MCP-сервер: например, в Cursor можно получить весь необходимый контекст и при необходимости редактировать его прямо из рабочей среды.
да, как только сервис будет наполнен и отлажен, сделаю публичным на github. Но пока есть идеи сделать плагин для VS Code или уйти в standalone...но это скорее идеи, чем что-то масштабируемое на долгий срок
Information
Rating
338-th
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
diff'ы magic flow у меня уже были заготовлены, так что статусы валидности и инвалидности потоков было не сложно сейчас добавить. Спасибо за хороший поинт. Я добавил валидацию потоков.
А насчет принятия новой версии потока - кажется тут зависит от слоя на котором он находится.
Если, допустим, поток находится на контекстном слое, то его может провалидировать и продуктовая часть команды, если же спускаемся до сервисов, то ответственный за интеграцию, или коллективно командами участвующих сервисов, но все-равно придется принять кому-то волевое решение, что оно работает так.
Но если уж есть архитектор, который прорабатывал данную интеграцию, то и он.
Все будет зависеть от слоя, на котором находится диаграмма, а так же практик принятых в отдельно взятых командах.
Очень хорошая мысль. Я часто думаю насчет того, как вообще поддерживать актуальность связей, потоков, сервисов и вообще всего ландшафта. С одной стороны можно актуализацию проводить после релиза контракта, зашить в CI актуализацию документации, потоков, контрактов и связей.
С другой стороны хочется иметь набор версий каждой связанности и при изменении контрактов действительно подсвечивать валидацию определенного magic flow.
К единому мнению еще не пришел.
Делаю похожий на него инструмент, но, как говорится с блекджеком. И точно не за десятки тысяч долларов для enterprise :)
Viaduct
На самом деле вы оба правы.
C4 всё же больше про послойное описание архитектуры, чем непосредственно про инфраструктуру. Но если смотреть на жизненный цикл каждого элемента, неизбежно возникает вопрос: как поддерживать всю эту документацию в актуальном состоянии?
С одной стороны, хочется уже на старте иметь понятный и полный набор моделей, связей и структур. С другой — важно, чтобы это «безобразие» не устаревало через несколько месяцев.
С первой частью обычно всё относительно понятно. Со второй часто возникают проблемы:
Нет централизованного процесса поддержки документации. Как ни унифицируй подходы, со временем команды всё равно начинают использовать инструменты и форматы, которые удобнее именно им.
Разработчикам и аналитикам естественно держать документацию рядом с кодом, в репозитории, и обновлять её через привычный процесс review и merge request’ов.
Не определён источник истины. Что считать реальностью: документацию, где были зафиксированы договорённости, или фактическую реализацию сервиса?
Для себя я пришёл к тому, что источником истины должны быть именно зафиксированные договорённости. Желательно, чтобы документация была трассируема до требований, реализации и тестов — и обратно. Тогда второй и третий пункты во многом решаются сами собой: документация становится частью инженерного процесса, а не побочным артефактом.
Кроме того, при современных AI-подходах документация может быть не только описанием уже реализованной системы. На её основе можно генерировать контракты, интерфейсы, каркасы сервисов и часть бизнес-логики.
Кстати, в моем сервисе для авторизованных пользователей доступен MCP-сервер: например, в Cursor можно получить весь необходимый контекст и при необходимости редактировать его прямо из рабочей среды.
да, как только сервис будет наполнен и отлажен, сделаю публичным на github. Но пока есть идеи сделать плагин для VS Code или уйти в standalone...но это скорее идеи, чем что-то масштабируемое на долгий срок