Как я перестал разрывать архитектуру на десяток документов — и сделал свой C4-редактор

[Void-Cowboy]

интересно

понятно что вайбкодинг, но не увидел в статье ссылку на исходники, я бы такое может быть даже бы себе в работу затянул

[igrglvk]

да, как только сервис будет наполнен и отлажен, сделаю публичным на github. Но пока есть идеи сделать плагин для VS Code или уйти в standalone...но это скорее идеи, чем что-то масштабируемое на долгий срок

[antirek]

С4 - вообще странная штука - с одной стороны архитектура на уровне систем, с другой схема таблиц в БД. хотя по идее это уровни разных людей. и если ты строишь архитектуру контура, то у тебя на сервисах API, которые тебе гарантируют контракты взаимодействия. а если строишь ПО, то пожалуйста, рисуй архитектуру программы, схемы БД и т.д. редактор, кстати, да прикольный.

[SiGGthror]

Архитектура не должна жить в отрыве от инфраструктуры. В конечном итоге архитектура - это способ достичь нужных гарантий в заданных ограничениях.

[antirek]

вот примерно шапка моего "пульта" связи кода с железом (ниже не буду показывать, много конкретики) т.е. от репозитория мы получаем артефакты (пакеты, images) и деплоим их на контуры. при этом меня не интересует что конкретные разрабы в конкретных репозиториях пишут, рисуют и реализуют (схемы БД, openapi specs). главное,чтобы потом в деплое были указаны все связи (какие БД, какие внешние сервисы). все сущности, все связи указаны в json. к этому json и другим данным имеет доступ агент, с которым можно проговорить детали, агент в описаниях обязательно рисует схемы в mermaid - очень понятно, подробно.

[SiGGthror]

И как это относится к предмету разговора? Мы про C4 и уровни архитектурного описания, а тут внезапно про инвентори деплоя. То, что у тебя есть JSON со связями и из него можно нарисовать Mermaid позволяет лишь получить определенный срез архитектуры, но это далеко не исчерпывающая информация. Если кому-то без разницы что там внутри сервисов происходит, не значит что всем должно быть без разницы.
Если понадобится проектировать хранилище данных, которое должно обрабатывать миллионы пользователей, внезапно выяснится что текущие ограничения железа вынуждают шардировать данные и здесь, как ни странно, схема БД становится очень важна.

[antirek]

да, важна, схема БД. но та, что реально лежит в проекте, а не нарисованная в документации. потому как, оп, разрабы их меняют по мере необходимости, и если у них там своя команда, и они отдельно принимают решения по архитектуре своего проекта, то ты по факту начинаешь сверять что у вас отличается. у меня в деплое как раз содержится инфо о связях с БД, чтобы понимать сколько там чего используется из железа.

ок, мне тоже "хотелось, чтобы система, её связи, сценарии и документация были одной навигационной моделью", и я ее все это хочу доставать прямо из кода. чтобы документация не догоняла. у меня такое получилось ))

[igrglvk]

На самом деле вы оба правы.

C4 всё же больше про послойное описание архитектуры, чем непосредственно про инфраструктуру. Но если смотреть на жизненный цикл каждого элемента, неизбежно возникает вопрос: как поддерживать всю эту документацию в актуальном состоянии?

С одной стороны, хочется уже на старте иметь понятный и полный набор моделей, связей и структур. С другой — важно, чтобы это «безобразие» не устаревало через несколько месяцев.

С первой частью обычно всё относительно понятно. Со второй часто возникают проблемы:

1. Нет централизованного процесса поддержки документации. Как ни унифицируй подходы, со временем команды всё равно начинают использовать инструменты и форматы, которые удобнее именно им.

2. Разработчикам и аналитикам естественно держать документацию рядом с кодом, в репозитории, и обновлять её через привычный процесс review и merge request’ов.

3. Не определён источник истины. Что считать реальностью: документацию, где были зафиксированы договорённости, или фактическую реализацию сервиса?

Для себя я пришёл к тому, что источником истины должны быть именно зафиксированные договорённости. Желательно, чтобы документация была трассируема до требований, реализации и тестов — и обратно. Тогда второй и третий пункты во многом решаются сами собой: документация становится частью инженерного процесса, а не побочным артефактом.

Кроме того, при современных AI-подходах документация может быть не только описанием уже реализованной системы. На её основе можно генерировать контракты, интерфейсы, каркасы сервисов и часть бизнес-логики.

Кстати, в моем сервисе для авторизованных пользователей доступен MCP-сервер: например, в Cursor можно получить весь необходимый контекст и при необходимости редактировать его прямо из рабочей среды.