13.Рекомендаций по проектирование слоев типовой архитек прилож.

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

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

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

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

Слой сервисов

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

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

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

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

Основные принципы проектирования

Рассмотрим основные принципы:

Слои приложения

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

 Явно определяйте связи между слоями. Решение, в котором каждый слой приложения может взаимодействовать или имеет зависимости со всеми остальными слоями, является сложным для понимания и управления. Принимайте явные решения о зависимостях между слоями и о потоках данных между ними.

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

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

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