Обзор архитектурных паттернов
Зачем нужны архитектурные паттерны
Архитектурный паттерн -- это проверенное решение для организации структуры программной системы. Он определяет:
- Как разделить код на компоненты
- Как компоненты взаимодействуют между собой
- Какие ограничения накладываются на зависимости
- Как система эволюционирует со временем
Без архитектурного паттерна код превращается в "Big Ball of Mud" -- неструктурированную массу, где всё зависит от всего.
Классификация архитектурных стилей
Монолитные архитектуры
┌─────────────────────────────────────────────────┐
│ МОНОЛИТНЫЕ АРХИТЕКТУРЫ │
├─────────────────────────────────────────────────┤
│ │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
│ │ Layered │ │ Modular │ │ Micro- │ │
│ │ (слоёная)│ │ Monolith │ │ kernel │ │
│ └───────────┘ └───────────┘ └───────────┘ │
│ │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
│ │ Hexagonal │ │ Onion │ │ Clean │ │
│ │ (порты и │ │(луковая) │ │(чистая) │ │
│ │ адаптеры) │ │ │ │ │ │
│ └───────────┘ └───────────┘ └───────────┘ │
│ │
└─────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────┐
│ РАСПРЕДЕЛЁННЫЕ АРХИТЕКТУРЫ │
├─────────────────────────────────────────────────┤
│ │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
│ │ Micro- │ │ Event- │ │ Space- │ │
│ │ services │ │ Driven │ │ Based │ │
│ └───────────┘ └───────────┘ └───────────┘ │
│ │
│ ┌───────────┐ ┌───────────┐ │
│ │ Service │ │ Pipe & │ │
│ │ Oriented │ │ Filter │ │
│ └───────────┘ └───────────┘ │
│ │
└─────────────────────────────────────────────────┘
Основные паттерны: краткий обзор
1. Layered Architecture (слоёная)
Самый распространённый паттерн. Код организован в горизонтальные слои, каждый из которых выполняет определённую роль.
┌─────────────────────────────────┐
│ Presentation Layer │ UI, API Controllers
├─────────────────────────────────┤
│ Business Logic Layer │ Services, Use Cases
├─────────────────────────────────┤
│ Persistence Layer │ Repositories, ORM
├─────────────────────────────────┤
│ Database Layer │ SQL, NoSQL
└─────────────────────────────────┘
Зависимости: сверху вниз ↓
Где используется: Большинство enterprise-приложений, традиционные PHP/Java-проекты.
Компании: eBay (ранние версии), многие банковские системы.
2. Hexagonal Architecture (порты и адаптеры)
Ядро приложения изолировано от внешнего мира через порты (интерфейсы) и адаптеры (реализации).
┌───────────┐
│ REST API │
│ (адаптер) │
└─────┬─────┘
│
┌────────────▼────────────┐
│ Входной порт │
│ (интерфейс) │
┌────┼─────────────────────────┼────┐
│ │ │ │
│ │ DOMAIN / БИЗНЕС │ │
│ │ ЛОГИКА │ │
│ │ │ │
│ │ Выходной порт │ │
└────┼────────┬────────────────┼────┘
│ │ │
└────────▼────────────────┘
│
┌──────▼──────┐
│ PostgreSQL │
│ (адаптер) │
└─────────────┘
Где используется: DDD-проекты, системы с множественными интеграциями.
Компании: Netflix (многие микросервисы), Spotify.
3. Onion Architecture (луковая)
Развитие идеи Hexagonal Architecture от Jeffrey Palermo. Зависимости направлены строго внутрь.
┌─────────────────────────────────────┐
│ Infrastructure │
│ ┌─────────────────────────────┐ │
│ │ Application Services │ │
│ │ ┌─────────────────────┐ │ │
│ │ │ Domain Services │ │ │
│ │ │ ┌─────────────┐ │ │ │
│ │ │ │ Domain │ │ │ │
│ │ │ │ Model │ │ │ │
│ │ │ └─────────────┘ │ │ │
│ │ └─────────────────────┘ │ │
│ └─────────────────────────────┘ │
└─────────────────────────────────────┘
Зависимости: снаружи внутрь →
Где используется: Сложные доменные приложения, где бизнес-правила -- главный актив.
4. Clean Architecture
Концепция Роберта Мартина (Uncle Bob). Обобщает Hexagonal и Onion, добавляя явные Use Cases.
┌────────────────────────────────────────┐
│ Frameworks & Drivers │
│ (Web, DB, UI, External APIs) │
│ ┌────────────────────────────────┐ │
│ │ Interface Adapters │ │
│ │ (Controllers, Gateways, │ │
│ │ Presenters) │ │
│ │ ┌────────────────────────┐ │ │
│ │ │ Application Business │ │ │
│ │ │ Rules (Use Cases) │ │ │
│ │ │ ┌────────────────┐ │ │ │
│ │ │ │ Enterprise │ │ │ │
│ │ │ │ Business │ │ │ │
│ │ │ │ Rules │ │ │ │
│ │ │ │ (Entities) │ │ │ │
│ │ │ └────────────────┘ │ │ │
│ │ └────────────────────────┘ │ │
│ └────────────────────────────────┘ │
└────────────────────────────────────────┘
Dependency Rule: зависимости ТОЛЬКО внутрь
Где используется: Проекты с долгим жизненным циклом, где важна заменяемость инфраструктуры.
5. Microkernel Architecture
Минимальное ядро с расширением через плагины. Ядро содержит только базовую функциональность.
┌─────────────────────────────────────────┐
│ Плагины │
│ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │ PDF │ │ CSV │ │ XML │ │ ... │ │
│ │Export│ │Import│ │Parse│ │ │ │
│ └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘ │
│ │ │ │ │ │
│ ┌──▼───────▼───────▼───────▼──┐ │
│ │ Plugin Registry │ │
│ │ (реестр плагинов) │ │
│ └──────────┬──────────────────┘ │
│ │ │
│ ┌──────────▼──────────────────┐ │
│ │ CORE SYSTEM │ │
│ │ (минимальная логика) │ │
│ └─────────────────────────────┘ │
└─────────────────────────────────────────┘
Где используется: IDE (VS Code, IntelliJ), браузеры (Chrome extensions), CMS (WordPress).
Компании: JetBrains, Eclipse Foundation, WordPress/Automattic.
6. Space-Based Architecture
Архитектура для систем с непредсказуемой нагрузкой. Устраняет единую базу данных как bottleneck.
┌─────────────────────────────────────────────┐
│ Processing Units │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Unit 1 │ │ Unit 2 │ │ Unit N │ │
│ │┌────────┐│ │┌────────┐│ │┌────────┐│ │
│ ││In-Memory││ ││In-Memory││ ││In-Memory││ │
│ ││ Grid ││ ││ Grid ││ ││ Grid ││ │
│ │└────────┘│ │└────────┘│ │└────────┘│ │
│ │┌────────┐│ │┌────────┐│ │┌────────┐│ │
│ ││ App ││ ││ App ││ ││ App ││ │
│ ││ Logic ││ ││ Logic ││ ││ Logic ││ │
│ │└────────┘│ │└────────┘│ │└────────┘│ │
│ └─────┬────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │
│ ┌─────▼─────────────▼─────────────▼─────┐ │
│ │ Data Replication Engine │ │
│ └───────────────────┬───────────────────┘ │
│ │ │
│ ┌───────────────────▼───────────────────┐ │
│ │ Data Writer / Reader │ │
│ └───────────────────┬───────────────────┘ │
└──────────────────────┼──────────────────────┘
│
┌──────▼──────┐
│ Database │
│ (eventual) │
└─────────────┘
Где используется: Системы продажи билетов, онлайн-аукционы, игровые платформы.
Компании: GigaSpaces, concert ticketing systems.
Сравнительная таблица
| Паттерн | Сложность | Тестируемость | Деплой | Масштабируемость | Стоимость |
|---|---|---|---|---|---|
| Layered | Низкая | Средняя | Простой | Низкая | Низкая |
| Hexagonal | Средняя | Высокая | Простой | Средняя | Средняя |
| Onion | Средняя | Высокая | Простой | Средняя | Средняя |
| Clean | Высокая | Высокая | Простой | Средняя | Высокая |
| Microkernel | Средняя | Высокая | Средний | Средняя | Средняя |
| Space-Based | Очень высокая | Средняя | Сложный | Очень высокая | Очень высокая |
Как выбрать архитектуру
Матрица решений
Простое CRUD-приложение?
├── ДА → Layered Architecture
└── НЕТ
Сложная бизнес-логика?
├── ДА → Hexagonal / Clean Architecture
│ Нужен DDD?
│ ├── ДА → Onion + DDD Tactical Patterns
│ └── НЕТ → Clean Architecture
└── НЕТ
Нужна расширяемость плагинами?
├── ДА → Microkernel
└── НЕТ
Непредсказуемая нагрузка?
├── ДА → Space-Based
└── НЕТ → Layered + модульность
Ключевые факторы выбора
| Фактор | Рекомендация |
|---|---|
| Маленькая команда, простой домен | Layered |
| Много внешних интеграций | Hexagonal |
| Сложные бизнес-правила | Clean / Onion + DDD |
| Расширяемость плагинами | Microkernel |
| Экстремальная нагрузка | Space-Based |
| Независимый деплой | Microservices |
| Асинхронные процессы | Event-Driven |
Эволюция архитектуры
Важно понимать: архитектура -- не статична. Большинство успешных систем проходят путь:
Монолит → Модульный монолит → Микросервисы
│ │
│ Layered → Hexagonal → Clean │
│ │
└──── Внутренняя архитектура ──────┘
Netflix: начинали как монолит на Java, перешли к микросервисам за 7 лет.
Amazon: монолитный книжный магазин → SOA → микросервисы.
Shopify: модульный монолит на Ruby on Rails -- осознанный выбор вместо микросервисов.
Антипаттерны
1. Architecture Astronaut
Выбор сложной архитектуры "на вырост" для простого проекта. CRUD-приложение на 3 таблицы не нуждается в Clean Architecture с CQRS.
2. Big Ball of Mud
Полное отсутствие архитектуры. Всё связано со всем. Добавление фичи ломает непредсказуемые части.
3. Golden Hammer
Использование одного паттерна везде. "У нас везде микросервисы" -- даже для внутренних тулзов на 2 пользователя.
4. Resume-Driven Architecture
Выбор технологий и паттернов для украшения резюме, а не для решения реальной задачи.