Вступление В этой статье я попытаюсь объяснить, что такое архитектура и чистая архитектура, а также роль архитектуры в проектах.
Примеры приложений веб-архитектуры
Давайте рассмотрим пример сервиса с одним архитектурным уровнем (одноуровневый)
В приложении с одним архитектурным уровнем пользовательский интерфейс, бизнес-логика, то есть внутренняя часть приложения и база данных находятся на одном сервере
Примером приложения с одним архитектурным уровнем являются такие приложения, как MS Office, GIMP
Преимущества использования однослойной архитектуры
- Очень небольшая задержка или отсутствие задержки во взаимодействии компонентов из-за того, что компоненты расположены на одном сервере
- Хотя это в значительной степени зависит от мощности машины и требований к программному обеспечению, для измерения реальной производительности одноуровневого приложения
- Кроме того, данные пользователя остаются на его компьютере и не нуждаются в передаче по сети. Это обеспечивает безопасность данных на самом высоком уровне. Данные клиента не могут быть перехвачены, так как обмен данными будет происходить на одном и том же сервере
Недостатки этой архитектуры
- Невозможность изменения кода или функций после доставки на рабочий сервер. Например, в 90-е годы, если игра поставлялась с ошибочным кодом, студии ничего не могли сделать
- Код в одноранговых приложениях также уязвим для переработки и обращения вспять. Безопасность бизнеса минимальна, поскольку в случае обратного проектирования злоумышленник или конкурент может получить доступ к вашей кодовой базе, что может привести к финансовым потерям. Пример – ваше приложение работает с финансами, злоумышленники раскрыли часть кода вашей системы и теперь могут обойти некоторые ваши проверки и, таким образом, использовать ваше приложение для мошенничества
Двухуровневая архитектура
Двухуровневое приложение включает в себя клиент и сервер. Клиент будет содержать пользовательский интерфейс и бизнес-логику на одном компьютере. И сервер будет внутренним приложением, развернутым на другом компьютере.
Бывают случаи, когда вам необходимо использовать двухуровневую архитектуру, например приложения со списком дел.
Трехуровневая архитектура
Трехуровневая архитектура довольно популярна и часто используется. Большинство простых веб-сайтов, таких как блоги, новостные сайты, используют эту архитектуру
Давайте рассмотрим пример простого блога – клиентский интерфейс будет написан с использованием HTML, JavaScript, CSS, а серверное приложение будет запущено на сервере, например Apache, а серверная часть будет использовать базу данных PostgreSQL в качестве хранилища
N-уровневая архитектура
Этот термин используется для описания архитектуры, в которой используется более трех компонентов. Примеры этих компонентов
- Кэш – пример такой технологии JCache, Кофеин. Эта технология используется для следующих целей – 1. Сократите время отклика приложения без запроса каких-либо данных в базе данных, 2. Также сохраните некоторые ответы от сторонних систем, так как это может занять очень много времени
- Брокер сообщений – примерами являются Apache Kafka, RabbitMQ. Этот инструмент необходим для сохранения любых сообщений, сообщение может означать какой-то запрос к сторонней системе, например, в Kafka вы можете хранить сообщения, которые нужно будет отправить в налоговую систему или оператору фискальных данных
- Балансировщик нагрузки – примерами являются Nginx, лента, Эврика. Этот инструмент необходим для распределения нагрузки на приложение. Представьте следующую ситуацию – у вас распределенное приложение, а это значит, что существует несколько экземпляров или узлов, и для оптимизации скорости для конечного пользователя все запросы проходят через балансировщик, который выбирает менее загруженный экземпляр/узел
- Поисковые сервисы – для поиска информации в огромных объемах данных
- Компоненты, отвечающие за обработку массивов данных
- Компоненты, использующие разнородные технологии, широко известные как веб-службы
Все современные социальные приложения – Instagram, Facebook и масштабируемые сервисы, такие как Uber, Airbnb, а также игры с огромным количеством игроков, такие как Pokemon Go, например, используют N-уровневую архитектуру
Чистая архитектура
Центром вашего приложения не является база данных. Архитектура также не является одной или несколькими фреймворками, которые вы можете использовать. В центре вашего приложения находятся варианты использования вашего приложения. Центром приложения является функциональность, за которую бизнес получает деньги, то есть, какую проблему/какую ценность ваше приложение приносит бизнесу – это место является центром приложения
Чистая архитектура – это набор практик, методов, шаблонов проектирования, которые позволяют создавать расширяемые и надежные приложения. Предназначен для предотвращения следующих проблем, которые могут возникнуть:
- Решения принимаются очень быстро – поспешные решения могут привести к проблемам, когда приложение находится на рабочем сервере
- Трудно вносить изменения
- Застрявший в определенных рамках – однажды организация/человек может решить, что у него/нее нет сил поддерживать эти рамки. Соответственно, вы не должны быть сильно привязаны к рамкам
- Фокусируясь только на технических аспектах – важно понимать, что при разработке вы должны фокусироваться не только на технических аспектах, но и на том, какую ценность для бизнеса представляет разработка новой функциональности принесет
- Трудно найти правильные места в проекте
- Бизнес-логика разбросана по всему коду – если какие-то требования изменятся, программисту придется найти все места в коде и изменить функциональность в каждом месте. Если бизнес-логика изолирована в одном месте, то программисту нужно только изменить код в одном месте
- Отсутствие тестов
- Нечастые обновления Чистая архитектура также обеспечивает следующие преимущества при использовании
- Эффективная стратегия тестирования
- Код для использования фреймворков изолирован
- Независимость от базы данных
- Вся бизнес-логика содержится в вариантах использования приложения
- Трудно поступить неправильно
- Приложение всегда готово к выходу в производственную среду
Давайте проанализируем эти цифры более подробно:
Ядром приложения является:
- Сущности, представляющие доменную область или предметную область. Предметная область приложения платежного шлюза – Интернет-финансы
- На этом уровне находится код, применимый ко всему объекту в целом (например, проверка формата имени хоста)
- Простые объекты Java: никаких рамок или аннотаций не требуется
Ядро:
- Представляет бизнес-действия вашего приложения – это то, что может делать ваше приложение.
- Чистая бизнес-логика, Java-код без использования каких-либо фреймворков, но с использованием утилитарных библиотек, таких как Apache Commons
- Определяет интерфейсы для данных, которые необходимы для применения логики. Один или несколько поставщиков данных реализуют интерфейс, но в случае использования неизвестно, откуда поступают данные
- На этом уровне генерируются бизнес-исключения – исключения, которые напрямую связаны с доменом приложения
Поставщики данных (поставщики данных):
- Получение и хранение данных из нескольких источников информации (базы данных, сетевых устройств, файловой системы и т.д.)
Точки входа в приложение:
- Этот уровень приложения описывает способ взаимодействия с приложением и обычно включает механизм доставки (например, API REST, запланированные задачи, графический интерфейс пользователя, другие системы).
- Запуск варианта использования и преобразование результата в формат, соответствующий механизму доставки
Конфигурация
- Соединяет все компоненты вместе
- Внедрение зависимостей здесь изолировано
- Содержат “грязные сведения” – такие как основной класс, конфигурация веб-сервера, конфигурация базы данных и т.д.
Архитектурный шаблон – это повторяющееся и общее решение проблемы, возникающей из-за проблемы архитектуры приложения в данном контексте.
Давайте взглянем на 10 популярных архитектурных моделей
- Многоуровневый
- Клиент-сервер
- Ведущий – ведомый
- Каналы и фильтры
- Шаблон посредника
- Одноранговый шаблон
- Автобус событий
- Модель – Вид -Контроллер
- Доска
- Переводчик
Многоуровневый
Он используется для структурирования программ, которые могут быть разбиты на группы определенных подзадач, расположенных на определенных уровнях абстракции. Каждый уровень предоставляет услуги для следующего более высокого уровня.
Чаще всего в общих информационных системах существует 4 уровня:
- Уровень представления (также известный как уровень пользовательского интерфейса)
- Уровень приложений (также известный как уровень обслуживания)
- Уровень бизнес-логики (также известный как уровень домена)
- Уровень доступа к данным (также известный как уровень хранения данных)
Использование
Обычные настольные приложения.
Электронная коммерция веб-приложений.
Клиент-Сервер
Этот шаблон состоит из двух частей: сервер и множество клиентов. Серверный компонент предоставляет услуги клиентским компонентам. Клиенты запрашивают услуги у сервера, а он, в свою очередь, предоставляет эти самые услуги клиентам. Более того, сервер продолжает “подслушивать” запросы клиентов.
Использование
Онлайн-приложения (электронная почта, обмен документами, банковские услуги).
Хозяин-Раб
Этот шаблон также включает в себя двух участников – хозяина и рабов. Лидер распределяет задания одинаковым Последователям и рассчитывает конечный результат на основе результатов, полученных от его “Подчиненных”.
Использование
В репликации базы данных. Там основная база данных считается авторитетным источником, а подчиненные базы данных синхронизируются с ней.
Периферийные устройства, подключенные к шине компьютера (ведущее и ведомое устройства).
Каналы и фильтры
Этот шаблон подходит для систем, которые генерируют и обрабатывают потоки данных. Каждый этап обработки происходит внутри компонента фильтра. Данные для обработки передаются по каналам. Эти каналы можно использовать для буферизации или синхронизации данных.
Использование
· Компиляторы. Последовательные фильтры выполняют лексический анализ, синтаксический анализ, семантический анализ и генерацию кода.
· Рабочие процессы в биоинформатике.
Шаблон посредника
Этот шаблон необходим для структурирования распределенных систем с отключенными компонентами. Эти компоненты могут взаимодействовать друг с другом посредством удаленного вызова службы. Компонент-посредник отвечает за координацию взаимодействия компонентов.
Сервер размещает свои возможности (услуги и характеристики) у посредника (брокера). Клиент запрашивает услугу у брокера. Затем брокер перенаправляет клиента на соответствующую службу из своего реестра.
Использование
· Брокеры сообщений по типу Apache ActiveMQ , Апач Кафка , Кролик/| и Обмен сообщениями JBoss .
Одноранговый шаблон
В этом шаблоне есть отдельные компоненты, так называемые одноранговые узлы. Одноранговые узлы могут выступать в качестве клиента, запрашивающего услуги у других одноранговых узлов (одноранговых узлов), и сервера, предоставляющего услуги другим одноранговым узлам. Одноранговый узел может быть клиентом или сервером, или всем сразу, и может динамически изменять свою роль с течением времени.
Использование
· Сети обмена файлами ( Gnutella и G2 )
· Мультимедийные протоколы ( P2PTV и PDTP )
· Проприетарные мультимедийные приложения (например, те же Spotify ).
Автобус событий
Этот шаблон в основном взаимодействует с событиями и имеет 4 основных компонента: источник событий, прослушиватель событий, канал и шина событий. Источники размещают сообщения для определенных каналов на шине событий. Слушатели подписываются на определенные каналы. Слушатели уведомляются о появлении сообщений, размещенных на каналах из их подписки.
Использование
Разработка для Android
Службы уведомлений
Модель – Вид -Контроллер
Этот шаблон также известен как шаблон MVC. Он делит интерактивные приложения на 3 части:
модель – содержит ключевые данные и функциональные возможности;
просмотр – показывает информацию пользователю (можно указать более одного представления);
контроллер – занимается обработкой данных от пользователя.
Это делается для того, чтобы отличать внутреннее представление информации от того, как она представлена и получена от пользователя. Такая конструкция изолирует компоненты и обеспечивает эффективное повторное использование кода.
Использование
· Архитектура WWW-приложений, написанных на основных языках программирования.
· Веб-фреймворки (например, Django и Rails )
Доска
Этот шаблон подходит для задач, для которых нет четких детерминированных решений. Шаблон платы состоит из 3 основных компонентов:
· доска представляет собой структурированную глобальную память, содержащую объекты из пространства возможных решений;
· источник знаний – специализированные модули с собственной презентацией;
· компоненты управления – выбирает, настраивает и выполняет модули.
Все компоненты имеют доступ к плате. Компоненты могут создавать новые объекты данных, которые добавляются на плату. Компоненты ищут определенные типы данных на плате. Один из способов поиска – сопоставить шаблоны с существующим источником знаний.
Использование
· распознавание речи;
· Идентификация и отслеживание транспортных средств;
· Определение структуры белка;
· Интерпретация сигналов гидролокатора.
Переводчик
Он подходит для разработки компонента, который должен интерпретировать программы, написанные на специальном языке программирования. В основном, он описывает, как оценивать строки (другими словами: “предложения” или “выражения”), написанные на каком-либо конкретном языке программирования. Смысл в том, чтобы присвоить класс каждому символу в языке.
Использование
· Языки запросов к базе данных (SQL);
· Языки, используемые для описания протоколов передачи данных.
Ниже приведены плюсы и минусы каждого из архитектурных шаблонов.
Многослойный Шаблон
Плюсы:
- Один низкий уровень может использоваться разными уровнями более высокого ранга.
- Слои упрощают стандартизацию, потому что мы четко определяем уровни.
- Изменения вносятся в пределах одного слоя, в то время как другие слои остаются неизменными.
Аферы:
- Не универсальный.
- В некоторых ситуациях можно пропустить некоторые слои.
Шаблон Клиент/Сервер
Плюсы:
- Набор услуг, которые могут запросить клиенты, подходит для моделирования.
Аферы:
- Запросы обычно выполняются в отдельных потоках на сервере.
- Взаимодействие между процессами увеличивает потребление ресурсов, поскольку разные клиенты имеют разные представления.
Шаблон Мастер-Последователь
Плюсы:
- Точность, потому что выполнение службы делегируется разным ведомым устройствам с разными реализациями.
Аферы:
- Все рабы изолированы, у них нет общего состояния.
- Период ожидания в связи между ведущим и ведомым является существенным недостатком. Например, в системах реального времени.
- Подходит только для тех задач, решение которых можно разложить на части.
Шаблон “Каналы и фильтры”
Плюсы:
- Они могут реализовывать параллельные процессы, когда ввод и вывод состоят из потоков, а фильтры начинают вычисления после получения данных.
- Простое добавление фильтров. Систему можно легко расширить.
- Фильтры пригодны для повторного использования. Они могут строить различные конвейеры, создавая всевозможные комбинации из существующего набора фильтров.
Аферы:
- Эффективность снижается из-за самых медленных процессов фильтрации. При переходе от одного фильтра к другому выполняется преобразование данных, что приводит к увеличению потребления ресурсов.
Шаблон посредника
Плюсы:
- Можно динамически изменять, добавлять, удалять и перемещать объекты. Этот шаблон делает процесс распространения прозрачным для разработчика.
Аферы:
- Необходимо стандартизировать описания услуг.
Одноранговый шаблон
Плюсы:
- Поддерживает децентрализованные вычисления. Чрезвычайно устойчив к сбоям на любом узле.
- Высокая масштабируемость с точки зрения ресурсов и вычислительной мощности.
Аферы:
- Нет никакой гарантии качества услуг; узлы сотрудничают спонтанно.
- Трудно гарантировать безопасность.
- Производительность зависит от количества узлов.
Шаблон шины событий
Плюсы:
- Легко добавляйте новых подписчиков, издателей и подключения. Хорошо работает для высокораспределенных приложений.
Аферы:
- Проблема с масштабируемостью, потому что все сообщения проходят через одну шину событий.
Шаблон контроллера модели-Представления
Плюсы:
- Облегчает создание различных представлений одной и той же модели; они могут быть включены или отключены во время выполнения.
Аферы:
- Сложность алгоритма возрастает. Может привести ко многим ненужным корректировкам действий пользователя.
Шаблон Доски
Плюсы:
- Простое добавление новых приложений.
- Вы можете легко расширить структуры пространства данных.
Аферы:
- Редактирование структур данных действительно сложно, потому что такие изменения затрагивают все приложения.
- Может потребоваться синхронизация и контроль доступа.
Шаблон “Переводчик”
Плюсы:
- Возможно очень динамичное поведение.
- Отличное решение для конечных пользователей с точки зрения удобства программирования.
Аферы:
- Проблемы с производительностью, поскольку интерпретируемый язык работает медленнее, чем скомпилированный.
Оригинал: “https://dev.to/vrnsky/software-architecture-1k7e”