Анализ архитектурных стилей: часть №2/9: стиль «монолит»

Сравнительная таблица архитектурных стилей

Сравнительная таблица архитектурных стилей

Введение

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

⚠ Заметка

1. Рассматривая очередной архитектурный стиль, например монолитный, для краткости будет писаться «монолит», а не «монолит»-стиль и/или «монолит»-архитектура, и/или «монолит»-система, и/или «монолит»-компонента, подразумевая, что целевой постфикс будет определяться в зависимости от контекста.

2. Не смотря на то, что итоговые показатели в сравнительной таблице, есть результат относительного сравнения стилей относительно друг друга, при описании стиля «монолит» не будут упоминаться другие стили, т.к. автор проводил сравнительный анализ в историческом контексте (от верхних стилей к нижним).

Оглавление

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

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

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

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

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

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

✔ Определение

Архитектурный стиль «монолит» — стиль разработки ПО, ориентированный на решение ТЗ, калибром не более 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 — посвященный архитектуре ПО:

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

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

© Habrahabr.ru