Разработка
Монолит
Также называют: монолитная архитектура, монолитное приложение
Определение
Монолит — приложение, которое собирается и разворачивается одним куском: весь код лежит в общем репозитории и выполняется в одном процессе, работает с одной базой и выкатывается целиком, что даёт простоту разработки ценой связанности.
Монолит — это архитектура по умолчанию, и это не оскорбление. Один процесс означает, что вызов между модулями — обычный вызов функции, а не сетевой запрос: он не падает по таймауту, его не нужно ретраить, его легко отладить. Одна база означает, что транзакция действительно транзакция и данные не разъезжаются. Один деплой означает, что нет версионного рассогласования между частями системы. Для большинства коммерческих проектов — сайтов, магазинов, личных кабинетов, внутренних систем — этого достаточно на годы вперёд.
Проблемы начинаются не от размера кода, а от отсутствия внутренних границ. Если модули свободно лезут в чужие таблицы, а бизнес-логика размазана по контроллерам, монолит превращается в «большой ком грязи»: любая правка задевает соседей, регресс становится непредсказуемым, а время сборки и релиза растёт. Отсюда рабочая середина — модульный монолит: единый деплой, но жёстко разделённые домены со своими границами и собственными таблицами, к которым обращаются только через внутренний интерфейс.
Практический критерий выбора звучит так: разделяйте на сервисы то, что реально требует независимого масштабирования, независимого релиза или отдельной команды, и не разделяйте остальное. Переход с модульного монолита на микросервисы — задача выполнимая, потому что границы уже проведены. Обратный путь, из преждевременных микросервисов назад в монолит, стоит существенно дороже, и такие проекты приходят на аудит регулярно: восемь сервисов, две штатные единицы и полгода на добавление одного поля в форму.
Смежные термины
- МикросервисыМикросервисы — архитектура, где приложение разбито на несколько самостоятельных сервисов со своими базами и релизным циклом: они общаются по сети через API, деплоятся независимо и масштабируются по отдельности, но требуют зрелой инфраструктуры.
- Легаси-кодЛегаси-код — работающий код, который дорого менять: он написан на устаревшем стеке, не покрыт тестами или потерял авторов, поэтому любая правка требует восстанавливать логику по исходникам и грозит поломкой в непредсказуемом месте.
- РефакторингРефакторинг — изменение внутренней структуры кода без изменения его внешнего поведения: функциональность до и после одинакова, меняются читаемость, связанность и стоимость следующей доработки, а результат подтверждается тестами и регрессом.
- Технический долгТехнический долг — накопленная разница между тем, как система устроена, и тем, как она должна быть устроена: каждое упрощение ради срока превращается в постоянную надбавку к стоимости и срокам всех последующих задач.
- CI/CDCI/CD — конвейер, который на каждый коммит автоматически собирает проект, прогоняет тесты и проверки, а затем выкладывает прошедшую сборку на тестовый стенд или в продакшн, убирая ручной деплой вместе с человеческим фактором.
Услуги по теме
- Разработка веб-приложений и Telegram Mini AppКогда сайта уже мало и нужен продукт: личный кабинет, дашборд, внутренний сервис или Mini App внутри Telegram. Проектируем архитектуру, пишем бэкенд и фронтенд, доводим до релиза.
- IT-консалтинг и продуктовый аудитСамые дорогие ошибки в разработке делаются до первой строчки кода: неверно понятая задача, стек, выбранный по привычке подрядчика, и ТЗ, которого нет. Консалтинг нужен, чтобы разобраться до того, как начнётся счётчик разработки: что именно строить, из чего, за сколько и в каком порядке. Результат — документ, а не мнение на созвоне.
- Разработка сайтов под ключДелаем сайты, которые не разваливаются через полгода: от одностраничника на CMS до магазина и веб-приложения на React и Next.js. Один подрядчик на дизайн, код, интеграции и запуск.
Почитать подробнее
- Как выбрать стек технологий для проекта: критерии, а не модаСтек выбирают на 3–5 лет вперёд, а решают за один созвон. Разбираем, в каком порядке принимать решения, какие критерии реально имеют вес, какие стеки работают для шести типов проектов и сколько стоит ошибка.
- Редизайн сайта без потери трафика: этапы, риски и SEO-чеклист переездаПоловина запросов на редизайн — это на самом деле проблемы контента, скорости или оффера. Разбираем, как отличить одно от другого, почему поэтапный вывод безопаснее большого запуска и что должно быть в чеклисте переезда, чтобы не потерять органику.
Нужна помощь с этим на практике?
Мы не только объясняем термины, но и делаем это руками. Опишите задачу — разберём и пришлём смету по этапам.