Почему так важна архитектура приложений?

Некоторые люди предпочитают работать вслепую, адаптируясь по мере обнаружения новых потребностей, практически не планируя. На рынке, где царит скорость, задержка проекта из-за невозможности адаптации архитектуры к потребностям может стать смертным приговором, поэтому так важно иметь четкую архитектуру приложения.

Все, что нужно знать об архитектуре приложений

Архитектура приложений - это структурная карта программных приложений в системе. В ней подробно описывается, как каждая единица программного обеспечения связана друг с другом и как они взаимодействуют для удовлетворения требований бизнеса или пользователей. Итак, если это просто диаграмма, то что в ней такого? Почему так много людей придают этому большое значение?

Подумайте об этом как о чертеже. Для очень маленьких проектов, скажем, для заделки трещины в стене, вы не станете беспокоиться о том, чтобы нарисовать всю схему вашего дома. Но если вы хотите построить дом, то это уже совсем другое дело. А как быть, если дом уже построен? Тогда ваш чертеж служит руководством к действию, если вы захотите переделать его в будущем.

Архитектуры приложений похожи тем, что помогают нам понять, как все устроено, и, таким образом, позволяют прогнозировать, что произойдет, если мы внесем изменения в систему. Другими словами, это мощный инструмент для разработки стратегии и планирования. Хорошо документированная архитектура - обязательное условие для беспрепятственного перехода, будь то изменение части нашей системы или масштабирование приложения.

Можете ли вы внести изменения в систему, не имея четкого представления о ее базовой архитектуре? Конечно. Является ли это плохой идеей? Очевидно. У архитекторов-программистов есть термин для приложений, собранных бессистемно: "spaghetti -архитектура" - лабиринт бессвязных зависимостей между различными частями приложения.
Так в чем же проблема "spaghetti -архитектуры"? Давайте посмотрим:

Плохая абстракция сервисов: Представьте себе, что ваши основные сервисы разбросаны по разным системам. Это не только чрезвычайно сложно для управления, но и затрудняет редактирование кода.
Эффект снежного кома: Когда компоненты не изолированы друг от друга, изменение одной части системы может вызвать цепную реакцию, которая приведет к краху всего приложения.
Негибкие унаследованные системы: Чем сложнее архитектура, тем труднее ее изменить. В свою очередь, тем меньше мотивация к ее обновлению, что способствует формированию культуры устаревания.

Каковы слои архитектуры приложений?

Программное обеспечение лучше всего представить в виде ряда слоев. На самом деле, это настолько хорошая аналогия, что она используется по умолчанию для большинства диаграмм AA. Если обобщить, то наиболее распространенными слоями архитектуры приложений являются:

презентационный слой
слой сервисов данных
уровень бизнес-логики
уровень доступа к данным

Другие модели имеют меньше или больше уровней, но с какой бы моделью вы ни работали, в ней всегда есть способ взаимодействия пользователей с приложением, способ доставки данных, основная система обработки, выполняющая вычисления, и место, где данные хранятся.

Презентационный слой

Этот слой связан с пользовательским интерфейсом, это та часть приложения, которая обрабатывает пользовательский ввод, управляет пользовательскими запросами, посылает запросы к сервисам данных, представляет выходные данные и, по сути, занимается всеми другими формами взаимодействия пользователя с приложением. Например, в случае веб-приложений это так называемый фронтенд, использующий такие технологии, как JavaScript, HTML и CSS, для создания той части сайта, которую потребляет клиент.

Слой обслуживания данных

Этот слой является связующим звеном между уровнем представления и уровнем бизнес-логики. С точки зрения безопасности он представляет собой стену, отделяющую действия пользователя от основной логики приложения, что делает его более безопасным для вас и ваших клиентов.

Слой бизнес-логики

На этом уровне происходит обмен или обработка данных, кодирование пользовательского ввода и/или подготовка информации для передачи на презентационный уровень. Например, в динамическом веб-приложении это та часть приложения, которая решает, какая информация требуется презентационному слою. Она получает информацию из хранилища данных, выполняет необходимую подготовку и отправляет ее для отображения пользователю.

Уровень доступа к данным

Здесь хранятся данные, чаще всего с использованием решений SQL или NoSQL. Это уровень, с которого осуществляется доступ к данным и их отправка.

Какие существуют различные типы архитектур приложений?

Хотя их слишком много, чтобы обобщить их в одной статье, вы должны, по крайней мере, знать, что существуют десятки архитектур. Некоторые из них более популярны, чем другие, и именно о них мы поговорим сегодня.

Монолитные архитектуры

Также известна как трехуровневая модель приложений. Хотя многие считают ее устаревшей по современным меркам, она все еще используется, особенно в унаследованных системах. В этой модели архитектура представляет собой единую монолитную структуру, управляемую одной командой. Приложение превращается в огромную систему переплетенных инструкций, которая по мере роста становится все более громоздкой.

Архитектура микросервисов

В этом архитектурном стиле приложение строится как набор независимых сервисов. Каждый из них может использовать различные технологии, например, быть написанным на разных языках программирования, и тестироваться отдельно от остальной системы. Каждый сервис связан с основной бизнес-функцией и может быть развернут отдельно от остальных.

Событийно-ориентированная бессерверная архитектура

Этот тип архитектуры функционирует как ряд разрозненных систем, которые запускаются в ответ на события. В этом случае мы имеем не серверы, а сервисы, которые ждут, пока что-то произойдет, чтобы отреагировать на это. Это очень компактная и быстрая архитектура, которая легко масштабируется и является экономически эффективной, поскольку используется только то, что необходимо, когда это необходимо.

Облачная архитектура

Эта архитектура похожа и на микросервисную, и на событийно-ориентированную, но с той оговоркой, что она специально разработана для максимального использования облачных технологий. Например, архитектура с возможностью автоматического масштабирования в зависимости от требований или сочетания различных сервисов одного или нескольких облачных провайдеров.

Никогда не поздно...

Что же делать, если у вас уже есть приложение без четкой архитектуры? Не слишком ли поздно? Конечно, нет, необходимость создания диаграммы на основе существующего приложения встречается гораздо чаще, чем хотелось бы. Чем раньше вы начнете, тем лучше, поскольку, как мы уже говорили, чем дольше вы ждете, тем больше погружаетесь в раздумья.