C4 всё же больше про послойное описание архитектуры, чем непосредственно про инфраструктуру. Но если смотреть на жизненный цикл каждого элемента, неизбежно возникает вопрос: как поддерживать всю эту документацию в актуальном состоянии?
С одной стороны, хочется уже на старте иметь понятный и полный набор моделей, связей и структур. С другой — важно, чтобы это «безобразие» не устаревало через несколько месяцев.
С первой частью обычно всё относительно понятно. Со второй часто возникают проблемы:
Нет централизованного процесса поддержки документации. Как ни унифицируй подходы, со временем команды всё равно начинают использовать инструменты и форматы, которые удобнее именно им.
Разработчикам и аналитикам естественно держать документацию рядом с кодом, в репозитории, и обновлять её через привычный процесс review и merge request’ов.
Не определён источник истины. Что считать реальностью: документацию, где были зафиксированы договорённости, или фактическую реализацию сервиса?
Для себя я пришёл к тому, что источником истины должны быть именно зафиксированные договорённости. Желательно, чтобы документация была трассируема до требований, реализации и тестов — и обратно. Тогда второй и третий пункты во многом решаются сами собой: документация становится частью инженерного процесса, а не побочным артефактом.
Кроме того, при современных AI-подходах документация может быть не только описанием уже реализованной системы. На её основе можно генерировать контракты, интерфейсы, каркасы сервисов и часть бизнес-логики.
Кстати, в моем сервисе для авторизованных пользователей доступен MCP-сервер: например, в Cursor можно получить весь необходимый контекст и при необходимости редактировать его прямо из рабочей среды.
да, как только сервис будет наполнен и отлажен, сделаю публичным на github. Но пока есть идеи сделать плагин для VS Code или уйти в standalone...но это скорее идеи, чем что-то масштабируемое на долгий срок
Информация
В рейтинге
601-й
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
На самом деле вы оба правы.
C4 всё же больше про послойное описание архитектуры, чем непосредственно про инфраструктуру. Но если смотреть на жизненный цикл каждого элемента, неизбежно возникает вопрос: как поддерживать всю эту документацию в актуальном состоянии?
С одной стороны, хочется уже на старте иметь понятный и полный набор моделей, связей и структур. С другой — важно, чтобы это «безобразие» не устаревало через несколько месяцев.
С первой частью обычно всё относительно понятно. Со второй часто возникают проблемы:
Нет централизованного процесса поддержки документации. Как ни унифицируй подходы, со временем команды всё равно начинают использовать инструменты и форматы, которые удобнее именно им.
Разработчикам и аналитикам естественно держать документацию рядом с кодом, в репозитории, и обновлять её через привычный процесс review и merge request’ов.
Не определён источник истины. Что считать реальностью: документацию, где были зафиксированы договорённости, или фактическую реализацию сервиса?
Для себя я пришёл к тому, что источником истины должны быть именно зафиксированные договорённости. Желательно, чтобы документация была трассируема до требований, реализации и тестов — и обратно. Тогда второй и третий пункты во многом решаются сами собой: документация становится частью инженерного процесса, а не побочным артефактом.
Кроме того, при современных AI-подходах документация может быть не только описанием уже реализованной системы. На её основе можно генерировать контракты, интерфейсы, каркасы сервисов и часть бизнес-логики.
Кстати, в моем сервисе для авторизованных пользователей доступен MCP-сервер: например, в Cursor можно получить весь необходимый контекст и при необходимости редактировать его прямо из рабочей среды.
да, как только сервис будет наполнен и отлажен, сделаю публичным на github. Но пока есть идеи сделать плагин для VS Code или уйти в standalone...но это скорее идеи, чем что-то масштабируемое на долгий срок