Анализ архитектурных стилей: часть №2/9: стиль «монолит»
Сравнительная таблица архитектурных стилей
Введение
Это вторая часть цикла из 9-ти статей, посвящённая сравнительному анализу стиля «монолит».
Предыдущая статья.
⚠ Заметка |
|---|
1. Рассматривая очередной архитектурный стиль, например монолитный, для краткости будет писаться «монолит», а не «монолит»-стиль и/или «монолит»-архитектура, и/или «монолит»-система, и/или «монолит»-компонента, подразумевая, что целевой постфикс будет определяться в зависимости от контекста. |
2. Не смотря на то, что итоговые показатели в сравнительной таблице, есть результат относительного сравнения стилей относительно друг друга, при описании стиля «монолит» не будут упоминаться другие стили, т.к. автор проводил сравнительный анализ в историческом контексте (от верхних стилей к нижним). |
Оглавление
Общее описание
Сравнительная классификация
2.1. Ключевые сильные стороны
2.2. Ключевые слабые стороны
Рекомендации к использованию
Общее описание
✔ Определение |
|---|
Архитектурный стиль «монолит» — стиль разработки ПО, ориентированный на решение ТЗ, калибром не более 2, обладающий следующими отличительными чертами: ► верхнеуровневая структура представлена в виде одного единственного компонента*; ► целевое ПО представлено в виде одного единственного артефакта**. |
* подразумевается, что простота этого компонента достаточная в том смысле, что нет необходимости выделять самостоятельные логические области.
** как правило, артефактом является исполнительный файл, но «монолит» так же может быть, например, библиотекой или иным программным модулем более сложной системы.
⚠ Заметка |
|---|
«монолит», исторически первый архитектурный стиль ПО, можно сказать «естественный», «который нельзя было не придумать», т.к. саму идею данного архитектурного стиля можно сформулировать через |
Сравнительная классификация
Ключевые сильные стороны
Const of Implementation (9/10)
«монолит» не подразумевает каких-либо специфических действий необходимых для обеспечения возможности реализации (нужен лишь компилятор и блокнот).
Const of ownershiping (9/10)
Стоимость владения «монолитом» либо бесплатна, либо ложится на плечи пользователя.
First/Next Deployability (9/10)
Первичная и последующие развёртывания системы на мощностях пользователя по факту являются лишь стандартной процедурой установки/переустановки целевого ПО.
Main-Structure (9/10)
Простейшая верхнеуровневая структура, является неоспоримым «преимуществом простоты» данного архитектурного стиля.
Infrastructure simplicity (9/10)
«монолит» ПО требует для своего функционирования только среду исполнения, от каковой, в худшем случае, требует только наличия специфических компонентов (библиотеки, утилиты, драйверы и т.д.).
Web-communication tolerance (9/10)
ПО, созданное в монолитном стиле, запускается на единственной машине из-за чего, даже если у данной машины возникнут проблемы с сетевым сообщением, ПО не упадёт, но просто зависнет на время до возобновления связи с внешним миром*.
* стоит отметить, что если «монолит» имеет сетевой доступ, то, либо ПО написано на высокоуровневых языках (Python, Go), коммуникационное взаимодействие для которых поставляется из коробки, либо представляет некоторую web-библиотеку/модуль, предназначенный для использования в других система.
Performance (10/10)
Приложения, построенные в монолитном стиле, обладают высочайшей из доступных (потенциально доступных) производительностью.
Testability (9/10)
Тестирование монолитных приложений является наиболее простым с технической точки зрения (для этого достаточно отладчика и, желательно, IDE).
Ключевые слабые стороны
Agility (2/10)
«монолит» не подразумевает ситуации постоянно меняющихся бизнес-требований, но подразумевает, что функциональные и нефункциональные требования формулируются единственный раз до начала реализации и не меняются на протяжении всего жизненного цикла*.
* если же, какие-либо из требований меняются, то, как правило, это повод задуматься о создании нового ПО в замен текущему.
Abstraction Level (2/10)
«монолит» не имеет какого-либо уровня абстракции в виду того, что на логическом уровне совокупная система не декомпозируется по компонентам*.
* появление в системе компонентов, требующих абстрагирования части своей логики/функционала от других компонентов на логическом уровне, как правило, требует абстрагирования/разделения и на уровне технической реализации, что является весомой причиной задуматься о смене архитектурного стиля.
Configurability (2/10)
«монолит» не подразумевает гибкость рода смены конфигурации* под запросы пользователя**.
* если вы начали мысли в эту сторону, то, вероятно, нуждаетесь в перепроектировании целевого ПО.
** исключением, однако, могут быть ситуации, когда монолитное приложение изначально создано как некоторый конструктор компонентов и/или инструмент конструирования, когда бы целевые задачи решались только в случае специфической настройки базисной модели (но по средствам конфигурационных файлов, без вмешательства в исходный код).
Domain portioning (1/10)
«монолит» — это один компонент и одна роль*!
* усложнять эту схему нельзя, либо же необходимо переходить на другие архитектурные стили.
Component-Structure Simplicity (2–9/10)
«монолит», будучи состоящим из одного единственного компонента*, образующего всю систему целиком, может дожить до ситуации, когда сложность такового компонента будет исключительно большой**.
* ситуация единственности компонента является не только отличительной чертой «монолита», но и его главным преимуществом, т.к. для того, что начать создавать ПО в этом стилей, нужно просто взять и начать программировать.
** в большинстве ситуаций, именно это обстоятельство является главной причиной перестройки приложения на новый архитектурный стиль.
Hardware fault tolerance (2/10)
«монолит», будучи лишь процессом в ОС, просто не может выполнять своих функций в случае отказа среды исполнения.
System component fault tolerance (2/10)
Поскольку «монолит», состоит из одного единственного компонента, то его отказ равносилен отказу всего ПО.
Technical Decomposition (2/10)
В «монолит» разделение по техническим ролям возможно только на микро-логическом* уровне и, частично, на уровне семантической структуры, но не более того**.
* отдельные простые классы и/или функции, но не целые блоки кода, имеющие специфическую внутреннею логику и скрывающие детали своей реализации.
** если вы начали думать, а целевом ПО так, что отделяете на логическом уровне различные части его функционала, то, это причина задуматься о смене архитектурного стиля.
Technical Evolvability (2/10)
Идеологически, «монолит» задуман как архитектурный стиль для построения ПО, решающее одну единственную задачу в конкретной, строго определённой области знаний, строго определёнными методами и потому в него изначально не закладывается какая-либо гибкость адаптации к меняющимся техническим условиям.
Elasticity (2/10)
Будучи лишь единственным процессом в ОС пользователя, монолитное приложение не имеет какой-либо власти над контролем за потребляемыми ресурсами.
Рекомендации к использованию
Односложные, однопоточные, простые программы, изолированные по данным и процессам их обработки, как правило не требующие сетевого взаимодействия* и предназначенные для решения одной ТЗ:
скрипты настройки окружения;
утилиты/демоны ОС;
вспомогательные/служебные программы/библиотеки;
отдельные модули/компоненты более сложных систем;
драйверы.
* либо изначально представляющие односложный компонент, предназначенные для обеспечения сетевого взаимодействия (таковыми являются различные коммуникационные библиотеки вплоть до транспортного уровня семиуровневой модели OSI).
Заключение
«монолит», слишком простая архитектура, чтобы делать о таковой какие-то существенные выводы, кроме, пожалуй, того, что если вы, будучи программистом, начали выполнять роль архитектора, думая над адекватностью и различного вида удобностью, разрабатываемого монолитного приложения, то, очевидно, настало время переходить на новые архитектурные стили.
Следующая статья (3/9) будет посвящена детальному описанию архитектурного стиля Modular Monolithic.
Заметки:
Статьи будут выходить примерно раз неделю.
Подписывайтесь на мой ТГ канал — t.me/TopITBlog — посвященный архитектуре ПО:
там даны ссылки на источники и на документ с уже готовым материалом;
учитывая, что развитие архитектуры ПО, процесс довольно неспешный, материалы в данном канале будут выходить редко (чаще обновляясь), а автор в свою очередь обязуется следить за актуальность уже представленной информации.
