Введение

Это вторая часть цикла из 9-ти статей, посвящённых сравнительному анализу архитектурных стилей.
Данная статья посвящена архитектурному стилю «монолит».
1/9 базовая статья с подробным описанием таблицы.

Оглавление

1. Общее описание

2. Сравнительная классификация

   2.1. Ключевые сильные стороны

   2.2. Ключевые слабые стороны
   

3. Рекомендации к использованию

Общее описание

* подразумевается, что простота этого компонента достаточная в том смысле, что нет необходимости выделять самостоятельные логические области.

** как правило, артефактом является исполнительный файл, но «монолит» так же может быть, например, библиотекой или иным программным модулем более сложной системы.

Сравнительная классификация

Ключевые сильные стороны

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 - посвященный архитектуре ПО:

• там даны ссылки на источники и на документ с уже готовым материалом;

• учитывая, что развитие архитектуры ПО, процесс довольно неспешный, материалы в данном канале будут выходить редко (чаще обновляясь), а автор в свою очередь обязуется следить за актуальность уже представленной информации.