Comments 5
интересно
понятно что вайбкодинг, но не увидел в статье ссылку на исходники, я бы такое может быть даже бы себе в работу затянул
С4 - вообще странная штука - с одной стороны архитектура на уровне систем, с другой схема таблиц в БД. хотя по идее это уровни разных людей. и если ты строишь архитектуру контура, то у тебя на сервисах API, которые тебе гарантируют контракты взаимодействия. а если строишь ПО, то пожалуйста, рисуй архитектуру программы, схемы БД и т.д. редактор, кстати, да прикольный.
Архитектура не должна жить в отрыве от инфраструктуры. В конечном итоге архитектура - это способ достичь нужных гарантий в заданных ограничениях.
вот примерно шапка моего "пульта" связи кода с железом (ниже не буду показывать, много конкретики) т.е. от репозитория мы получаем артефакты (пакеты, images) и деплоим их на контуры. при этом меня не интересует что конкретные разрабы в конкретных репозиториях пишут, рисуют и реализуют (схемы БД, openapi specs). главное,чтобы потом в деплое были указаны все связи (какие БД, какие внешние сервисы). все сущности, все связи указаны в json. к этому json и другим данным имеет доступ агент, с которым можно проговорить детали, агент в описаниях обязательно рисует схемы в mermaid - очень понятно, подробно.
И как это относится к предмету разговора? Мы про C4 и уровни архитектурного описания, а тут внезапно про инвентори деплоя. То, что у тебя есть JSON со связями и из него можно нарисовать Mermaid позволяет лишь получить определенный срез архитектуры, но это далеко не исчерпывающая информация. Если кому-то без разницы что там внутри сервисов происходит, не значит что всем должно быть без разницы.
Если понадобится проектировать хранилище данных, которое должно обрабатывать миллионы пользователей, внезапно выяснится что текущие ограничения железа вынуждают шардировать данные и здесь, как ни странно, схема БД становится очень важна.
Как я перестал разрывать архитектуру на десяток документов — и сделал свой C4-редактор