Дима пишет | Дмитрий Смотров: заметки с тегом модульный_монолит

Модульный монолит (5)

Tue, 05 Nov 2024 01:13:11 +0300

Хочу подвести итоги темы модульного монолита.

1) Монолит — система, состоящая из одной единицы развертывания.
2) Монолит по умолчанию не комок грязи, в его определение такого нет в принципе
3) Модульный монолит — монолит, спроектированный с учетом модульности.
4) Модульный компонент — независим, автономен и имеет четкий интерфейс

Стоит помнить особенности разработки и эксплуатации монолитных систем:
1) Более легкий порог вхождения для разработки — думаю, тут все понятно.
2) Запуская проект для локальной разработки — вы запускаете ВЕСЬ проект. Был я на проекте, где с учетом размера кодовой базы и мощностей рабочего железа процесс локального развертывания мог занимать полчаса. Удовольствие очень сомнительное, скажу я вам. Желательно в таком случае иметь тестовые стенды, в которых вы можете подкинуть свои изменения и проверить выполненную работу на них.
3) Деплой монолита — это деплой всех его модулей. Опять же, с ростом кодовой базы процесс становится дольше, отсюда у разных компаний могут появляться свои системы сборки, с точечной оптимизацией процесса развертывания, свои отделы выпусков, которые будут следить за окончанием работ над каждым модулем и соблюдением режима тишины. Буду надеятся, что внутрь подобных систем сборки залить вам не придется :)
4) Иногда разработчикам двух разных модулей приходится ждать друг друга — ведь чтобы запустить сборку изменение второго разработчика, нужно будет дождаться сборки изменений первого. Обычно это касается работы в крупном энтерпрайзе.
5) Масштабируемость. Возможны ситуации, когда определенные модули потребляют ресурсов больше, чем все остальные. К сожалению, нельзя добавить мощностей только для нагруженных модулей, вернее вертикальное масштабирование сервера приложения позволит это сделать, но ВМ конечно. А при горизонтальном масштабировании, добавляя новый экземпляр приложения, мы так же закладываем ресурсы для модулей, которые не нуждаются в дополнительных ресурсах. Как итог — теряем деньги на лишние вычислительные мощности. Не факт, что подобные потери будут велики, но стоит это учитывать. (тут должна быть шутка про то, как AWS выставляет чек на крупную сумму, так как ты не отключил автомасштабирование облака).
6) Сломана нога — умирает весь человек. Если один из модулей падает с критической ошибкой, все приложение падает на пол, вся команда разрабов сидит и чинит прод на выходных, либо же просто сидит отдыхает, пока виновник торжества исправляет ситуацию, отбиваясь от дубликатов ошибок и нависшего над душой менеджера.
7) Использование сторонних технологий. В рамках монолита нельзя использовать разные ЯП(исключения есть, но не о них сейчас). Поэтому резко начать впихивать rust у вас не получится, как использовали php, так и используйте :)

Модульный монолит (4)

Tue, 05 Nov 2024 01:11:45 +0300

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

Для понимания того, как модульность выглядит на уровне приложения обратимся к схеме:

Оранжевый и сиреневый квадраты — это модули Бизнес Логики(БЛ).
Зеленые линии — это тоже модули, но модули технические.

В контексте данной темы технические модули называют «слоями», а модули БЛ «модулями», так как чаще всего изменения и разработка касаются бизнес логики — добавляются новые фичи, изменяется поведение старых и тому подобное.

На схеме отображено взаимодействия модулей бизнес логики с техническими слоями приложения. Каждый модуль реализует собственную функциональность, используя возможности слоев БД, логики приложения(обмен сообщений, запуск фоновых задач, ...) через контракты(интерфейсы).

Мы можем изменить реализацию и способ хранения данных, но модуль «Orders» ничего не заметит, он как использовал нужные ему вызовы методов слоя БД, так и использует. Можем поменять визуальное представление сущностей модуля «Payments», модулю все равно, он отдает со своей стороны данные по контракту и получает объект-представление, как и было оговорено в контракте.

Модули БЛ добавляются, приложение растет, полезных действия приложения становится больше, и еще длительное время проект спокойно развивается в рамках такой архитектуры.

Модульный монолит(3)

Mon, 04 Nov 2024 23:56:10 +0300

Продолжим по модульный монолит.

Если монолитная архитектура почти всегда скатывается в «комок грязи», а модульность должна нас от этого комка спасти. Давайте поймем, что такое «модуль».

Модуль — независимый участок кода, содержащий все необходимое для выполнения только одного аспекта желаемой функциональности. Состоит из интерфейса и реализации.
Интерфейс модуля выражает элементы, которые предоставляются и требуются модулем. Элементы, определенные в интерфейсе, могут быть обнаружены другими модулями.
Реализация содержит рабочий код, соответствующий элементам, объявленным в интерфейсе.

Модулем как правило называют модуль бизнес-логики приложения(модуль почтовой рассылки), но так же есть «инфраструктурные» модули(модуль для работы с БД, очередью и так далее).

Модуль должен обладать следующими свойствами:
1) Независимостью — зависимости модуля сведены к минимуму и частота изменений «родительских» модулей минимальна. Так же снижаем сцепленность и увеличиваем связность.
2) SRP — модуль решает четко определенную задачу.
3) имеет четко определенный интерфейс — контракт для взаимодействия с другими модулями. Хороший контракт — непротиворечивый и минимальный. Интерфейс модуля должен быть стабильным(не подвергаться частому изменению).