---
aliases:
  - монолитном аду
tags:
  - зрелость/🌱
date:
  - - 2024-04-04
zero-link:
  - "[[00 Архитектура ПО]]"
parents: 
linked:
  - "[[Монолитная архитектура]]"
---
Монолитный ад появляется, когда команда монолита и кодовая база разрастается. Приложение становится настолько большим, что одному разработчику его невозможно понять.

![](a46f1a15-51d7-4007-8116-0d6b936c5cd1.png)

Усугубляет проблему то, что сложность, и так чрезмерная, обычно повышается экспоненциально. Если кодовая база плохо поддается пониманию, разработчик не сможет внести изменения подходящим образом. Каждое изменение усложняет код и делает его еще менее понятным. В итоге вы получаете [Большой комок грязи](Большой%20комок%20грязи.md).

**Медленная разработка.** Сборка кода занимает много времени. Из-за размеров приложения оно долго запускается. В итоге затягивается цикл написания - сборки - запуска - тестирования.

**Медленные и сложные релизы.** Над проектом работает множество команд, а кодовая база у них одна. В итоге если даже монолит разбит на отдельные модули, ваша команда не сможет выпустить релиз, пока другие команды не закончат свои работы.

**Трудности с масштабированием.** Разные программные модули конфликтуют/соревнуются за ресурсы сервера. Например, модуль обработки изображений сильно нагружает ЦПУ, и это может сказаться на стабильности работы других модулей.

**Сложно добиться надежности и стабильности работы.** Утечка памяти в одном модуле приводит к отказу всего решения.

**Постепенное устаревание стека технологий.** Сложно переходить на новые фреймворки и подходы в монолитном приложении, посколько это чаще всего невозможно сделать точечно. Нельзя сказать, что модуль оплаты мы разрабатываем на спринге, а модуль пользователей на кваркусе.