Анализ архитектурных стилей: часть №3/9: стиль «модульный монолит»
Сравнительная таблица архитектурных стилей
Введение
Это третья часть цикла из 9-ти статей, посвящённых сравнительному анализу архитектурных стилей.
Данная статья посвящена стилю архитектурному стилю «модульный монолит».
1/9 базовая статья с подробным описанием таблицы.
2/9 предыдущая статья, посвящённая стилю «монолит»
⚠ Для кого полезна данная статья |
|---|
1. Если вы опытный разработчик и/или архитектор, то для вас будет полезна только сама таблица. |
2. Если вы начинающий разработчик и/или адепт мира ПО, то имеет смысл читать весь текст в той последовательности, которую предлагает автор. |
⚠ Заметка перед прочтением |
|---|
1. Все статьи данного цикла не преследуют цель давать рецепты о том, как делать можно и нужно, и как никогда нельзя! |
2. Автор хочет особенно отметить, что все статьи не более чем про теорию в контексте классификации, т.е. наиболее разумно относиться к представленной здесь информации, как к попытке с высока обозреть и оценить текущую ситуацию в сфере эволюции архитектуры ПО. |
3. Некоторые ценные комментарии читателей обязательно будут учтены по факту завершения цикла статей и, вероятно, приведут к незначительному расширению представленной таблицы (прошу отнестись к этому не быстрому процессу с пониманием, терпением и толерантностью). |
4. Если среди читателей есть такие, кто хочет скорейшим образом донести свои наблюдения/замечания/корректировки, то прошу всех не равнодушных создавать pull-request в данный репозиторий. |
Оглавление
Общее описание
Сравнительная классификация
2.1. Ключевые сильные стороны
2.2. Ключевые слабые стороны
Области использования
Общее описание
«модульный монолит» является естественным развитием стиля «монолит», отличаясь от него тем только, что теперь «монолит» представляется в виде модулей.
✔ Определение |
|---|
Модуль — это компонент ПО, обладающий следующими свойствами: • выполняет в ПО строго определённую функцию/роль/задачу: • скрывает от остальных компонентов детали своей реализации; • представлен в виде подгружаемого артефакта ПО. |
Сущностно, «модульный монолит» не привносит ничего нового, кроме того, что теперь ПО на уровне артефактов выглядит ни как один единственный исполняемый файл, но как исполняемый файл и некоторое количество библиотек (dll), подгружаемых либо сразу, либо по факту запроса соответствующего функционала.
Сравнительная классификация
⚠ Заметка |
|---|
Правила выставления оценок подробно описаны в первой статье. |
Ключевые сильные стороны
Const of Implementation (9/10)
«модульный монолит» привносит дополнительную сложность по сравнению с «монолитом», выраженную в необходимости иметь адекватную, гибко конфигурируемую систему сборки*.
* Таковые, однако, обильно представлены в современном мире ОП (Make, CMake, Maven, и другие…).
Const of ownershiping (8–9/10) аналогично «монолиту»
First/Next Deployability (9/10) аналогично «монолиту»
Infrastructure simplicity (9/10) аналогично «монолиту»
Web-communication tolerance (9/10) аналогично «монолиту»
Performance (9/10)
Разделение ПО на компоненты может повлечь накладные расходы на обмен данными между ними, но, в общем и целом, «модульный монолит» может вплотную приблизиться по производи-тельности к стилю «монолит».
Testability (8–9/10)
Могут возникнуть некоторые сложности с отладкой на этапе загрузки dll*.
* данная проблема хорошо решается использованием современных IDE (VisualStudio, CLion, QtCreator, и другие…)
Technical Decomposition (10/10)
«модульный монолит» поощряет архитекторов к тому, чтобы на этапе проектирования ПО, разделять его на компоненты, независимые по техническим ролям.
Ключевые слабые стороны
Domain portioning (2–4/10)
«модульный монолит» позволяет разделять ПО на компоненты, независимые по зоне ответственности, но не по роли в полноценном смысле, т.к. каждый из таковых компонентов продолжает являться структурной частью целевого ПО.
Hardware fault tolerance (2/10) аналогично «монолиту»
System component fault tolerance (1/10)
Если «монолит» состоит из одно компонента, отказ которого равносилен краху всей системы, то система построенная по архитектуре «модульного монолита» падает с (условно) N-раз большей вероятностью, где N — это количество модулей*.
* стоит отметить, что данный показатель выделен красным только в реалиях сравнительной таблицы, тогда как в реальной жизни, подобный недостаток стиля «модульный монолит» не приводит к отказу от его использования, т.к. почти полностью нивелируется грамотным предрелизным тестированием.
Technical Evolvability (3/10)
«модульный монолит» крайне требователен к тому, чтобы все технические роли были определены и продуманы ещё на этапе проектирования ПО, т.к. внесение изменений в таковые на этапе реализации и поддержки может быть очень и очень сложным*.
* как показывает практика, «модульный монолит», это именно тот стиль где редко бывает ошибочным заложить в систему больше гибкости чем это требуется в контексте требований текущего момента.
Elasticity (2–5/10)
Формально, «модульный монолит» ничем не отличается от «монолита» в смысле возможностей контролировать потребляемые ресурсы, однако, на практике «модульный монолит» — это уже довольно значительное по объёмам кода и функционалу ПО, которое управляет процессом загрузки/выгрузки целевых компонентов и исполняет их программный код в параллельных потоках.
Области использования
⚠ Заметка |
|---|
1. «модульный монолит» можно считать родоначальником паттернов в разработке ПО, т.к. идея делить ПО на компоненты, дала толчок созданию концепций такого разделения, первыми среди которых были: Model-View-Controller (MVC), Model-View-Presenter (MVP), Model-View-Presenter-ViewModel. |
2. Именно с появлением архитектурного стилям «модульный монолит» получили распространение программы, выполняющихся во множестве потоков одновременно, и классическим воплощением этой концепции стала технология OpenMP. |
Многопоточное ПО, локализованного типа, предназначенное для решения конкретных задач, обобщённых единой областью знаний/методологией решения/подходом к решению:
Заключение
«модульный монолит» можно долго описывать по разному и с различных сторон, т.к. способов воплотить этот стиль на практике существует огромное количество и, уверен, со временем будет ещё больше в виду того, что прямо или косвенно, модульный подход лежит в основе всех последующих архитектурных стилей хотя бы на уровне использования сторонних библиотек.
Но, автор, хочет предложить следующее умозаключение относительно рассмотренного стиля: «модульный монолит» хорош тогда, когда создаваемое по его лекалам ПО, будучи сердцем некоторой компании, не требует для себя организационно-штатной структуры большей сложности, чем в:
Следующая статья (4/9) будет посвящена детальному описанию архитектурного стиля Microkernel.
Заметки:
Подписывайтесь на мой ТГ канал — t.me/TopITBlog:
там даны ссылки на источники и на документ с уже готовым материалом;
учитывая, что развитие архитектуры ПО, процесс довольно неспешный, материалы в данном канале будут выходить редко (чаще обновляясь), а автор в свою очередь обязуется следить за актуальность уже представленной информации.
