Что такое бизнес слой приложения

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

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

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

Никита Соболев «Паттерны и бизнес-логика для вашего Vue приложения»

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

Сервис может обрабатывать большое число взаимодействий с потребителями, поэтому попытки сохранять состояние для каждого отдельного потребителя в бизнес-слое могли бы обусловить потребление слишком большого объема ресурсов. Это привело бы к ограничению числа запросов, которые может обрабатывать сервис в любой момент времени. Реализуйте все бизнес-сущности в отдельной сборке. Эта сборка представляет разделяемый компонент, который может использоваться и бизнес-слоем, и слоем доступа к данным. Однако обратите внимание, что бизнес-сущности не должны предоставляться через границы сервиса; для передачи данных между сервисами используйте объекты передачи данных (data transfer objects, DTO). Вопросам реализации бизнес-слоя посвящена глава 7, « Рекомендации по проектированию бизнес-слоя ». Более подробно бизнес-сущности рассматриваются в главе 13, « Проектирование бизнес-сущностей ».

Сетевое взаимодействие

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

Если сервис будет развертываться в закрытой сети, можно использовать более эффективный протокол связи Transmission Control Protocol (TCP). Если сервис будет развертываться в публичной сети, следует выбирать протокол Hypertext Transfer Protocol (HTTP).

Выработайте стратегию обработки ненадежной или неустойчивой связи, возможно, с применением кэширования сообщений с последующей их передачей при возобновлении соединения, а также обработки асинхронных вызовов. Примите решение о том, будет ли связь односторонней или двухсторонней, и есть ли необходимость в применении шаблонов Duplex, Request Response и Request-Reply. Используйте динамический подход к формированию URL-адреса конечных точек для обеспечения максимальной гибкости и определите, как будете проверять адреса конечных точек в сообщениях. Выберите соответствующие протоколы связи и обеспечьте защиту данных, передаваемых по каналам связи, с помощью шифрования и/или цифровых подписей. Более подробно протоколы и техники связи рассматриваются в главе 18, « Взаимодействие и обмен сообщениями ».

#Архитектура приложения и кода

Слой доступа к данным

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

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

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

Всегда используйте абстракцию при реализации интерфейса слоя доступа к данным. Как правило, это обеспечивается применением шаблонов Data Access или Table Data Gateway, в которых типы входных и выходных данных определены. Для каждой таблицы или представления базы данных создайте класс для реализации простых операций Create, Read, Update и Delete (CRUD). Это обеспечивает шаблон Table Module, в котором каждой таблице поставлен в соответствие класс с операциями, взаимодействующими с этой таблицей. Спланируйте обработку транзакций. Избегайте применения олицетворения или делегирования для доступа к базе данных, используйте для этого общую сущность, обеспечивая при этом данные удостоверения

пользователя, чтобы процессы протоколирования и аудита могли ассоциировать пользователей с осуществляемыми ими действиями. Более подробно реализация слоя доступа к данным обсуждается в главе 8, « Рекомендации по проектированию слоя доступа к данным ».

Управление исключениями

Проектирование эффективной стратегии управления исключениями имеет большое значения для обеспечения безопасности и надежности сервисного приложения, в противном случае, оно будет уязвимым для атак Отказа в обслуживании (Denial of Service, DoS) и может допустить разглашение конфиденциальных или критически важных данных. Формирование и обработка исключений является ресурсоемкой операцией, поэтому важно, чтобы стратегия управления исключениями разрабатывалась с учетом влияния на производительность.

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

Не допускайте разглашения конфиденциальных данных в исключениях сервисах, файлах журналов и файлах аудита. Перехватывайте только те исключения, которые можете обработать, например, для удаления из них конфиденциальных данных или введения дополнительных данных. Не используйте исключения для управления логикой приложения. Избегайте использования собственных исключений, когда в них нет крайней необходимости. Используйте SOAP-элементы Fault или специальные расширения для возвращения данных исключения вызывающей стороне. Более подробно проектирование стратегии управления исключениями рассматривается в главе 17, « Сквозная функциональность ».

Структура сообщения

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

При проектировании структуры сообщений руководствуйтесь следующими рекомендациями: Выбирайте соответствующие шаблоны для структуры сообщения (такие как Command, Document, Event и Request-Response). Разделяйте очень большие объемы данных на меньшие блоки и отправляйте их последовательно.

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

Конечная точка сообщения

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

При проектировании конечных точек сообщений руководствуйтесь следующими рекомендациями: Выбирайте соответствующие шаблоны конечных точек сообщений (такие как Gateway, Mapper (Преобразователь), Competing Consumer и Message Dispatcher). При проектировании предусмотрите сценарии без подключения.

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

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

Обеспечьте коммутативность. Коммутативность – это ситуация, когда сообщения могут поступать в произвольном порядке. Иначе говоря, коммутативная конечная точка гарантирует, что поступающие в произвольном порядке сообщения будут сохранены и впоследствии обработаны в правильном порядке.

Защита сообщений

При обмене конфиденциальными данными между сервисом и его потребителем необходимо обеспечить защиту сообщений. Для этого может использоваться защита на транспортном уровне (посредством протоколов IPSec или SSL) или защита на уровне сообщения (посредством шифрования и цифровых подписей). При проектировании стратегии защиты сообщений руководствуйтесь следующими рекомендациями: Используйте безопасность на уровне сообщения, если требуется обеспечить сквозную безопасность и существует вероятность наличия между сервисом и вызывающей стороной посредников, таких как серверы и маршрутизаторы. Безопасность на уровне сообщения помогает защитить конфиденциальные данные в сообщениях путем их шифрования. Применение цифровых подписей поможет защититься от отказа

Источник: studfile.net

4 типа архитектуры программного обеспечения

Первые разработчики создавали программное обеспечение без архитектуры. Сначала это казалось удобным: никаких издержек, связанных с планированием, и ускоренное прототипирование. Но мере усложнения ПО теряло гибкость и управляемость, а каждое новое изменение обходилось все дороже. Это мешало развивать проект за границы, определенные изначально. Такая система получила название Большой комок грязи (Big Ball of Mud).

За годы развития ПО разработчикам удалось придумать надежные подходы, чтобы устранить недостатки проектирования без архитектуры. Ниже представлены некоторые из самых известных.

• Многослойная архитектура (Layered Architecture).
• Многоуровневая архитектура (Tiered Architecture).
• Сервис-ориентированная архитектура (Service Oriented Architecture — SOA).
• Микросервисная архитектура (Microservice Architecture).

Подробно рассмотрим каждую из них.

Многослойная архитектура

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

Архитектура делит ПО на следующие слои.

• Слой представления (Presentation Layer) содержит пользовательский интерфейс и отвечает за обеспечение хорошего пользовательского опыта.
• Слой бизнес-логики (Business Logic Layer), как следует из названия, содержит бизнес-логику приложения. Он отделяет UI/UX от вычислений, связанных с бизнесом. Это позволяет с легкостью изменять логику в зависимости от постоянно меняющихся бизнес-требований, никак не влияя на другие слои.
• Слой передачи данных (Data Link Layer) отвечает за взаимодействие с постоянными хранилищами, такими как базы данных, и прочую обработку информации, которая не связана с бизнесом.

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

Преимущества

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

Недостатки

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

Многоуровневая архитектура

Этот архитектурный подход разделяет комплекс ПО на уровни по принципу взаимодействия “клиент-сервер”. Архитектура может иметь один, два и больше уровней, разделяющих ответственности между поставщиком данных и потребителем.

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

Одноуровневая система

В данном подходе единая система работает как на стороне сервера, так и клиента. Это обеспечивает простоту развертывания и отличную скорость связи, а также устраняет необходимость межсистемного взаимодействия (Inter-system communication — ISC).

Такая система подходит только для небольших однопользовательских приложений.

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

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

• Клиент содержит слои презентации, бизнес-логики и передачи данных.
• Сервер включает хранилища и базы данных.

Трехуровневая и n-уровневая системы

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

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

Сервис-ориентированная архитектура (SOA)

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

Она состоит из 5 элементов:

• сервисы (Services);
• сервисная шина (Service Bus);
• сервисный репозиторий (Service Repository catalogue of services );
• безопасность SOA (SOA Security);
• управление SOA (SOA Governance).

Клиент отправляет запрос с использованием стандартного протокола и формата данных по сети. Этот запрос обрабатывается ESB (enterprise service bus — сервисная шина предприятия), которая считается сердцем сервис-ориентированной архитектуры и отвечает за оркестровку и маршрутизацию. С помощью сервисного репозитория ESB направляет запрос в специальный сервис, который может взаимодействовать с другими сервисами и базами данных, чтобы составить полезную нагрузку (данные) ответа.

Полный вызов ответа на запрос согласуется с правилами управления и безопасности SOA для выполнения безопасной и корректной транзакции.

Как правило, сервисы делятся на два вида.

1. Атомарные сервисы (Atomic services) предоставляют функциональности, которые не подлежат дальнейшей декомпозиции.
2. Композиционные сервисы (Composite services) сочетают в себе несколько атомарных сервисов, чтобы предоставлять сложную составную функциональность.

Типы сервисов

• Организационные сервисы (Entity service).
• Доменные сервисы (Domain Service).
• Вспомогательные сервисы (Utility Service).
• Интегрированный сервис (Integrated Service).
• Сервис приложений (Application Service).
• Сервис безопасности (Security Service).

Mикросервисная архитектура

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

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

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

Состав микросервисов

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

• сервисы (Services);
• сервисная шина (Service Bus);
• внешняя конфигурация (External configuration);
• шлюз API (API Gateway);
• контейнеры (Containers).

Характеристики микросервисов

Микросервисная архитектура должна включать следующие характеристики.

• Компонентизация через сервисы.
• Организация вокруг бизнес-возможностей.
• Ориентирована на продукты, а не проекты.
• Умные конечные точки и глупые каналы (Smart endpoints and dumb pipes).
• Децентрализованное управление.
• Децентрализованное управление данными.
• Автоматизация инфраструктуры.
• Защита от сбоев.
• Эволюционное проектирование.

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

Преимущества

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

Недостатки

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

• Мы снова написали самый быстрый JS-фреймворк UI
• 3 совета, как стать мастером Йода по JavaScript
• 10 полезных инструментов для фронтенд-разработчика

• ТЭГИ
• Software Architecture

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

Архитектура приложений: определение, описание и руководство

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

Многослойная архитектура

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

• простой в реализации;
• абстрактной;
• защищенной за счет изолированности каждого слоя;
• легко управляемой и масштабируемой.

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

• одноуровневая,
• двухуровневая,
• трехуровневая.

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

• клиент,
• сервер для обработки,
• базы данных для хранения.

Микросервисная архитектура приложений

• изолированность каждого отдельного компонента;
• сбой одного компонента не затрагивает работоспособность всего приложения;
• удобно масштабировать и внедрять обновления;
• и др.

Заключение

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