Как разработать архитектуру программы

Содержание

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

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

Логика довольно проста: когда пользователь вводит URL-адрес в браузере и нажимает «ввод», браузер делает запрос к серверу. Сервер отвечает, а затем показывает требуемую веб-страницу. Все эти компоненты создают архитектуру веб-приложения.

Как работает системная архитектура для веб-приложений?
Все приложения состоят из двух частей — клиентской (front-end) и серверной (back-end).

Интерфейс — это визуальная часть приложения. Пользователи могут видеть интерфейс и взаимодействовать с ним. Клиентский код реагирует на действия пользователей. Серверная часть не визуальна для пользователей, но заставляет их запросы работать. Он обрабатывает бизнес-логику и отвечает на HTTP-запросы.

Создаем масштабируемую архитектуру

Поэтому, когда вы вводите свои учетные данные в регистрационную форму, вы имеете дело с внешним интерфейсом, но как только вы нажимаете «ввод» и регистрируетесь — это серверная часть заставляет его работать.

При правильной работе клиентская и серверная стороны составляют архитектуру программного обеспечения веб-приложения.

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

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

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

Структурные компоненты состоят из клиентской и серверной сторон:
Клиентский компонент разработан с HTML, CSS или JavaScript. Веб-браузеры запускают код и преобразуют его в интерфейс, поэтому нет необходимости в настройке операционной системы.

Что касается серверного компонента, он построен на Java, .Net, Node.JS, Python и других языках программирования. Сервер состоит из двух частей — логики приложения и базы данных. Логика приложения — это центр управления веб-приложением. База данных отвечает за хранение информации (например, ваших учетных данных).

Уровни архитектуры веб-приложений
Существует четыре общих уровня веб-приложений:

Уровень представления (PL)
Уровень обслуживания данных (DSL)
Уровень бизнес-логики (BLL)
Уровень доступа к данным (DAL)

🚀Собираем масштабируемую архитектуру веб-приложения. Горизонтальное и вертикальное масштабирование

Слой бизнес-логики
BLL несет ответственность за надлежащий обмен данными. Этот уровень определяет логику бизнес-операций и правил. Вход на сайт — это пример уровня бизнес-логики.

Уровень службы данных
DSL передает данные, обработанные уровнем бизнес-логики, на уровень представления. Этот уровень гарантирует безопасность данных, изолируя бизнес-логику со стороны клиента.

Уровень доступа к данным
DAL предлагает упрощенный доступ к данным, хранящимся в постоянных хранилищах, таких как двоичные файлы и файлы XML. Уровень доступа к данным также управляет операциями CRUD — создание, чтение, обновление, удаление.

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

Одностраничные веб-приложения
Многостраничные веб-приложения
Архитектура микросервисов
Бессерверная архитектура
Прогрессивные веб-приложения

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

Известные СПА : Gmail, Facebook, Twitter, Slack.

Многостраничное приложение или MPA
Многостраничные приложения более популярны в Интернете, так как в прошлом все веб-сайты были MPA. В наши дни компании выбирают MPA, если их веб-сайт довольно большой (например, eBay). Такие решения перезагружают веб-страницу для загрузки или отправки информации с / на сервер через браузеры пользователей.

Известные MPA: eBay, Amazon.

Одностраничное приложение или многостраничное приложение ? У многостраничного и одностраничного приложения есть недостатки и преимущества.

Архитектура микросервисов
Чтобы понять архитектуру микросервисов , лучше сравнить ее с монолитной моделью.

Архитектура программного обеспечения – принципы, методы и стили

dzen

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

Что такое плохая архитектура и как ее распознать?

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

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

Что такое хорошая архитектура и какими свойствами она обладает?

Просто — Легко понять.
Модульность/многослойность/Четкость — Это важно для того, чтобы один слой мог изменяться независимо от других с минимальной связью между слоями
Гибкий/расширяемый— Может быть легко адаптирован к новым меняющимся требованиям
Тестируемый/поддерживаемый — Легко тестируемый, добавляйте автоматизированные тесты и поощряйте культуру TDD и, следовательно, легко поддерживаемый

Зачем беспокоиться об архитектуре, принципах, практиках?

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

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

Оптимизация — Регулярно задумывайтесь о рефакторинге кода. Это позволит содержать большие объемы кода в чистоте и порядке.

Оптимизация производительности — Не делайте оптимизации производительности кода, пока не достигните LRT.

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

Каким инструментам, методологиям и методам мы можем следовать?

Lean методология — Создайте правильную вещь. Постройте то, что необходимо.
Agile методология— Постройте правильный путь. Создавайте программное обеспечение таким образом, чтобы оно было гибким, адаптируемым и быстро реагировало на меняющиеся требования рынка
Практика разработки на основе тестов и автоматизированных тестов (TDD) – Практика, при которой тесты пишутся до того, как будет написан сам код приложения. Что позволяет писать исключительно легко поддерживающийся код. Покрытие тестами близится к настоящим 100%.

Каким архитектурным стилям следовать?

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

Доменно-ориентированная архитектура (Domain Centric Architecture)
Архитектура, ориентированная на приложения (Application Centric Architecture)
Кричащая Архитектура (Screaming Architecture)
Архитектура микросервисов (Microservices architecture)
Архитектура, управляемая событиями (Event-Driven Architecture, EDA)
Разделение ответственности за командные запросы (Command Query Responsibility Segregation, CQRS)

Доменно-ориентированная архитектура

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

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

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

Плюсы

Это позволяет использовать мышление, основанное на предметной области (DDD). Основное внимание уделяется домену, пользователям и вариантам использования.
Уменьшена связь между доменом (стабильным и меньше меняется) и деталями реализации (которые меняются быстрее, например, уровень представления, база данных).

Минусы

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

Ориентированное на приложение (Многоуровневая архитектура)

Как только граница домена определена, следующим идет уровень приложения. Прикладной уровень становится надежным благодаря применению нижеприведенных SOLID принципов.

Абстракции (ЧТО?) — Приложение должно быть построено таким образом, чтобы оно могло содержать бизнес-логику с использованием абстракций. Он должен сосредоточиться на том, что(?) он хочет делать.

Сегрегация(КАК?) — это сделано, аспект деталей реализации можно подключить с помощью инъекции зависимостей(DI). DI применяется не только для внедрения бизнес-логики с использованием различных шаблонов проектирования, но и конкретно применяется при внедрении элементов инфраструктуры, таких как базы данных, кэш, серверы уведомлений, внешние веб-службы и т.д.

Интерфейсы/Контракты — Такой подход автоматически создает многоуровневую архитектуру с четкими интерфейсами для каждого внешнего элемента. Разделение ответственности в сочетании с тем, что каждый слой владеет одной-единственной ответственностью, уменьшает сцепление. Это, в свою очередь, помогает легко тестируемому коду, который также может быть протестирован с помощью моков (mocks).

Опять же, уровень приложений не зависит ни от каких других деталей реализации и имеет только знания о доменном уровне, от которого он зависит.

Функциональная организация кода (кричащая архитектура)

Архитектура должна кричать о намерениях системы — дядя Боб

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

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

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

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

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

Архитектура, управляемая событиями (EDA)

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

В EDA есть 3 участника, а именно производитель, который создает запускающее событие, посредник сообщений, который надежно передает сообщение, и потребитель, который может подписаться на конкретное или на все события. Это приводит к “реактивному программированию”, которое реагирует на событие(триггер), поступающее из потока данных, что приводит к более быстрому времени отклика и, следовательно, к низкой задержке.

Для микросервисов, которым требуются ACID свойства транзакций между микросервисами с использованием возможной согласованности, вместо EDA используется шаблон SAGA, в котором используется явный механизм отката для обработки условий ошибок для отката изменений. Это, однако, усложняет конструкцию, поэтому следует использовать с осторожностью.

EDA также породила Event Sourcing в качестве нового механизма хранения данных в БД. Здесь объекты БД никогда не обновляются. Вместо того, чтобы получить текущее состояние объекта, создается путем применения событий в том же порядке, в каком они были получены. Оптимизация производительности достигается в источнике событий путем создания моментальных снимков текущего состояния с фиксированными интервалами.

Шаблон CQRS-Разделение ответственности за командные запросы

Появление микросервиса и EDA также породило шаблон CQRS. Команда-это то, что изменяет состояние базового объекта, и запрос не изменяет объект, а просто возвращает запрошенное подмножество объектов.

Чем это полезно? Несколько примеров

Вы можете улучшить масштабируемость чтения, не влияя на запись. Например, добавив дополнительные дополнительные узлы в MongoDB для удовлетворения требований к чтению, вы выборочно масштабируете возможность чтения.
Команда должна отправить обновления в базу данных. Вы можете выбрать уровень кэширования для обеспечения более быстрого чтения.
Иногда объект может принадлежать другому микросервису, и каждый раз запрос к другому микросервису может быть дорогостоящим, поэтому вы можете использовать уровень кэширования для своих запросов. Данные дублируются, но до тех пор, пока они сохраняются и меняются не очень быстро, вы можете значительно сократить задержку. Это иногда также обеспечивает устойчивость. Даже если другой микросервис недоступен, ваш микросервис может продолжать нормально работать. например, Кэширование каталога продуктов в заказе-микросервисе.

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

Источник: maxyc.ru