Введение
Это третья часть цикла из 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. |
Многопоточное ПО, локализованного типа, предназначенное для решения конкретных задач, обобщённых единой областью знаний/методологией решения/подходом к решению:
различные CAD системы;
редакторы документов (без коллаборации);
простые игры.
Заключение
«модульный монолит» можно долго описывать по разному и с различных сторон, т.к. способов воплотить этот стиль на практике существует огромное количество и, уверен, со временем будет ещё больше в виду того, что прямо или косвенно, модульный подход лежит в основе всех последующих архитектурных стилей хотя бы на уровне использования сторонних библиотек.
Но, автор, хочет предложить следующее умозаключение относительно рассмотренного стиля: «модульный монолит» хорош тогда, когда создаваемое по его лекалам ПО, будучи сердцем некоторой компании, не требует для себя организационно-штатной структуры большей сложности, чем в:
один project holder;
один-два project managers;
2-8 team leaders;
не более 50 программистов и тестировщиков.
Следующая статья (4/9) будет посвящена детальному описанию архитектурного стиля Microkernel.
Заметки:
Подписывайтесь на мой ТГ канал - t.me/TopITBlog:
там даны ссылки на источники и на документ с уже готовым материалом;
учитывая, что развитие архитектуры ПО, процесс довольно неспешный, материалы в данном канале будут выходить редко (чаще обновляясь), а автор в свою очередь обязуется следить за актуальность уже представленной информации.