Multitier

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

нижестоящие слои не должны зависеть от вышестоящих;
каждый слой не должен быть осведомлен о вышестоящем, но должен предоставлять определенный набор открытых функций. Чем более стандартизированной и универсальной будет реализация, тем безболезнее будет выполняться замена слоя (при необходимости).

Плюсы

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

Минусы

чем больше слоев, тем сложнее сопровождать и развивать систему в целом;
горизонтальное масштабирование все так же сложнодостижимо (как и при монолитной архитектуре);
возможна деградация системы в связи с невозможностью замены одного или нескольких слоев аналогами - система становится похожа на анти-паттерн Big Ball of Mud.

История развитие

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

Первый этап. Приложения были больше похожи на монолитные. Как правило, имели только 2 слоя - консоль для передачи команд и бизнес-слой с логикой приложения;
Второй этап. Состоит уже из 3 слоев - UI (реализованный с использованием web, консоли, мобильного приложения или desktop интерфейса), бизнес-слоя с логикой приложения и источника данных (новый слой относительно первого этапа). На втором этапе приложения стали разделять на клиент-серверные части, что стало классической реализацией и по сей день.
Третий этап. Количество слоев осталось прежним, но наполнение слоев значительно усложнилось. В связи с бурной диджитализацией различных областей жизни человека, системам потребовалось расширение, а следовательно и усложнение. На данном этапе окончательно сформировалась трех-уровневая (three-tier, n-tier) архитектура. Важной особенностью стало четкое разделение слоев друг от друга и слабая связанность между ними.
Четвертый этап. На текущий момент, является самой совершенной реализацией многослойного приложения, а так же, наиболее часто применяемого для систем низкой и средней сложности. Ключевым источником идеи явлется Domain-Driven архитектура, которая выделяет 4 слоя приложения:
- Слой интерфейсов - сюда можно отнести внешнюю оболочку, а так же интерфейсы для доступа к данным другим системам посредством стандартных (и не только) протоколов (например, HTTP);
- Слой приложения - слой, принимающий запросы клиентов системы (людей или внешних систем) на выполнение тех или иных действий;
- Слой бизнес-логики - слой, отвечающий за работу бизнес-логики приложения, сущности, обмен данных между сущностями, действия приложения над данными и объектами и т.д. Основной слой, выполняющий всю оперативную работу;
- Инфраструктурный слой - вспомогательный слой, выполняющий задачи в зависимости от приложения, например, для хранения данных, отправки сообщений, взаимодействие с другими системами и т.д.

Архитектара

Важно соблюдать баланс требований и реализации и не добавлять в приложение ненужные слои, усложняя тем самым работу и потенциал для развития приложения.

Многослойное приложение так же имеет риски для прихода к свойственному ей анти-паттерну:

Чрезмерный акцент на слоях. При реализации простой задачи, каждый слой должен быть задействован (в соответствии с иерархией) - это приводит к созданию ненужных прокси объектов, которые выполняют функцию лишь транспорта данных;
Чрезмерная абстракция. Изобилие абстракций приводит к большому количеству элементов языка, которые ничего не выполняют;
Слишком много ненужных слоев. Бывает что некоторые слои не нужны, но они все равно добавляются в связи с требованиями стандартов архитектуры;
Выделение слоев по их функциональному назначению (слой хранения, UI-слой, API-слой, бизнес-логика и т.д.), вместо организации в соответствии с компонентами приложения (продукт, заказ, доставка, и т.д.). Это приводит к тому что поддержке и развитию функциональных частей приложения уделяется больше внимания, чем самому продукту.

Литература

2002 – Martin Fowler – Patterns of Enterprise Application Architecture
2003 – Eric Evans – Domain-Driven Design: Tackling Complexity in the Heart of Software
2011 – Chris Ostrowski – Understanding Oracle SOA – Part 1 – Architecture