Проектирование архитектуры

Обзор

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

Как я это строю

Доменная логика остаётся чётко отделена от инфраструктуры. Собственный контентный движок этого сайта следует тому же правилу: схема сущностей понятия не имеет и не должна иметь, что GitHub оказался слоем хранения под ней. Где хранится состояние — база данных, граф, векторное хранилище или кэш — решается явно, исходя из того, что реально моделируется, а не по привычке или потому что в прошлом проекте было так.

Целевая платформа развёртывания формирует дизайн с самого начала, а не пристраивается потом. Хороший пример — собственное решение этого сайта пререндерить каждый маршрут: аудитория включает ИИ-краулеров, а не только людей с браузером и JavaScript, так что это решение пришлось принять рано. И компромиссы фиксируются на бумаге, а не только в виде диаграмм. Понимание того, почему решение было принято, важно не меньше, чем понимание того, каким оно получилось — особенно через полгода, когда кто-то пытается его поменять.

Кому это подходит

Основателям и командам, начинающим что-то нетривиальное, которым важнее сразу заложить правильный фундамент, чем переделывать его после второго продакшен-инцидента.

FAQ