28 lines
3.0 KiB
Markdown
28 lines
3.0 KiB
Markdown
|
---
|
|||
|
|
aliases:
|
|||
|
|
- монолитном аду
|
|||
|
|
tags:
|
|||
|
|
- зрелость/🌱
|
|||
|
|
date:
|
|||
|
|
- - 2024-04-04
|
|||
|
|
zero-link:
|
|||
|
|
- "[[00 Архитектура ПО]]"
|
|||
|
|
parents:
|
|||
|
|
linked:
|
|||
|
|
- "[[Монолитная архитектура]]"
|
|||
|
|
---
|
|||
|
|
Монолитный ад появляется, когда команда монолита и кодовая база разрастается. Приложение становится настолько большим, что одному разработчику его невозможно понять.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Усугубляет проблему то, что сложность, и так чрезмерная, обычно повышается экспоненциально. Если кодовая база плохо поддается пониманию, разработчик не сможет внести изменения подходящим образом. Каждое изменение усложняет код и делает его еще менее понятным. В итоге вы получаете [Большой комок грязи](Большой%20комок%20грязи.md).
|
|||
|
|
|
|||
|
|
**Медленная разработка.** Сборка кода занимает много времени. Из-за размеров приложения оно долго запускается. В итоге затягивается цикл написания - сборки - запуска - тестирования.
|
|||
|
|
|
|||
|
|
**Медленные и сложные релизы.** Над проектом работает множество команд, а кодовая база у них одна. В итоге если даже монолит разбит на отдельные модули, ваша команда не сможет выпустить релиз, пока другие команды не закончат свои работы.
|
|||
|
|
|
|||
|
|
**Трудности с масштабированием.** Разные программные модули конфликтуют/соревнуются за ресурсы сервера. Например, модуль обработки изображений сильно нагружает ЦПУ, и это может сказаться на стабильности работы других модулей.
|
|||
|
|
|
|||
|
|
**Сложно добиться надежности и стабильности работы.** Утечка памяти в одном модуле приводит к отказу всего решения.
|
|||
|
|
|
|||
|
|
**Постепенное устаревание стека технологий.** Сложно переходить на новые фреймворки и подходы в монолитном приложении, посколько это чаще всего невозможно сделать точечно. Нельзя сказать, что модуль оплаты мы разрабатываем на спринге, а модуль пользователей на кваркусе.
|