Модульный монолит (1)
В моих целях на ближайшие полгода лучше разобраться с практиками и архитектурными подходами, которые применяются в моей текущей работе. Начать я захотел с такого понятия, как «Модульный монолит». Кому интересно аргументированно пообщаться — прошу под кат.
Монолитная архитектура — это традиционная универсальная модель проектирования ПО. Монолитный в данном контексте значит собранный в единое целое. Компоненты программы связаны и взаимозависимы, а не обладают слабой связанностью (_low coupling — >прим. перев._), как в случае модульных программ.
Описание выше — пример очень плохой ситуации, когда происходит «утечка БЛ»(или же сильное сплетение разных компонентов). Подобную систему поддерживать — очень дорого по трудозатратам и деньгам. Все наладом дышит, а капельницы для проекта заканчиваются быстрее, чем новые подвозят.
Я уверен, что читатель в своих проектах с пеной у рта отказывается вливать конструкции с таким количеством связей в разные стороны, в том числе когда код «воюет не в ту сторону». Кроме случаев, когда дедлайн ближе, чем кажется(вы же берете себе задачу для улучшение подобного кусочка кода в ближайшее после хотфиксов время?).
И тут у меня возникает вопрос: а зачем из каждого утюга орут, что монолит — это мерзость, которую всеми правдами и неправдами нужно избегать? Ребят, а вы зачем лезете в микросервисы, когда есть возможность добавить модульность в монолит, использовать между модулями четкие интерфейсы и в определенный момент(он сам к вами придет) вырезать нужные сервисы из достаточно опрятного монолита? Какое учение несет ваша церковь? Кто среди вас главный евангелист?
Разберемся.