Что такое архитектура приложения?

Question

claude-haiku-4.5 · Accepted Answer

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

Для Business Analyst архитектура — это не техническая деталь для разработчиков. Это фундамент для принятия решений о roadmap, сроках разработки и рисках. За 10+ лет я научился думать об архитектуре в контексте бизнеса, а не только технологии.

### Основное определение

**Архитектура приложения** — это проект, который описывает:
1. Как компоненты системы организованы
2. Как они взаимодействуют
3. Какие технологии используются
4. Как масштабируется система при росте пользователей/данных
5. Как система справляется с ошибками и сбоями

Проще говоря: это blueprint, как приложение построено, прежде чем писать код.

### Архитектура с точки зрения Business Analyst

## 1. Почему это важно для бизнеса?

**Скорость разработки**
Хорошая архитектура позволяет разработчикам добавлять новые фичи быстро.
- Плохая архитектура: каждая новая фича требует переписания 3 других модулей (сроки растут)
- Хорошая архитектура: нужно добавить 2-3 функции в правильном месте (быстро)

**Пример:** Когда я работал в SaaS компании с плохой архитектурой, добавить новый report занимало 2 недели. После рефакторинга архитектуры (разделили monolith на микросервисы) — 2 дня. ROI рефакторинга был очевиден.

**Стоимость разработки**
Хорошая архитектура = меньше bugs = меньше переделок = меньше затрат на разработку.

**Масштабируемость**
Может ли система обслуживать 10x больше пользователей без полной переписи? Это решение архитектуры.
- Плохая архитектура: система рушится при 100K одновременных пользователей
- Хорошая архитектура: масштабируется до миллионов

**Риск и надёжность**
Если архитектура предусматривает резервирование, то система продолжит работать даже при сбое одного сервера. Это критично для финансов, healthcare, e-commerce.

## 2. Основные типы архитектуры

### Монолит (Monolithic)

**Как работает:** Всё приложение в одном большом коде. База данных одна на всех.

**Пример структуры:**
```
MyApp/
  ├── auth/
  ├── users/
  ├── products/
  ├── orders/
  ├── payments/
  └── database.py
```

**Плюсы:**
- Просто развернуть (один сервер)
- Быстро разрабатывать features в начале
- Транзакции между модулями просты
- Нет network overhead

**Минусы:**
- Трудно масштабировать (если orders перегружен, вся система страдает)
- Трудно разрабатывать параллельно (две команды работают в одном коде)
- Один bug может рушить всё приложение
- Трудно обновить одну часть без риска сломать другую

**Когда использовать:** Стартап с <5 разработчиков, не требует масштабирования в ближайший год.

### Микросервисы (Microservices)

**Как работает:** Приложение разбито на отдельные независимые сервисы. Каждый имеет свою БД, API, разработчиков.

**Пример структуры:**
```
API Gateway
  ├── Auth Service (порт 3001)
  ├── User Service (порт 3002)
  ├── Product Service (порт 3003)
  ├── Order Service (порт 3004)
  └── Payment Service (порт 3005)
```

Каждый сервис может быть написан на Python, Java, Go — разные language разные технологии.

**Плюсы:**
- Масштабируемость: можно запустить 10 копий Order Service, если нужно
- Независимость: Payment Service может быть down, остальное работает
- Параллельная разработка: разные команды работают независимо
- Обновления без downtime (blue-green deployment)

**Минусы:**
- Сложнее разрабатывать (нужно думать об API между сервисами)
- Сложнее тестировать (transaction что-то может зависать в сети)
- Сложнее мониторить (больше логов, больше точек отказа)
- Race conditions: если Order Service вызывает Payment Service, а тот timeout-ится?
- Стоит дороже (нужна инфраструктура для оркестрации сервисов)

**Когда использовать:** Масштабирующийся продукт, >20 разработчиков, разные команды отвечают за разные сервисы.

### Слойная архитектура (Layered / N-tier)

**Как работает:** Приложение разделено на горизонтальные слои. Запрос "падает" через все слои.

**Слои (снизу вверх):**
1. **Database Layer** — прямая работа с БД (SQL queries)
2. **Data Access Layer** — ORM, queries
3. **Business Logic Layer** — правила бизнеса (расчёты, валидация)
4. **Presentation Layer** — API endpoints, JSON responses, Web UI

**Пример flow для запроса "Create Order":**
```
API Endpoint receives POST /orders
  ↓
Presentation Layer validates input
  ↓
Business Logic Layer (checks stock, calculates price)
  ↓
Data Access Layer (ORM creates order record)
  ↓
Database stores data
  ↓
Response goes back up with order ID
```

**Плюсы:**
- Понятная структура (каждый слой имеет одну ответственность)
- Легко тестировать (можешь протестировать бизнес-логику без БД)
- Масштабируемость в ширину (добавить сервер)

**Минусы:**
- Масштабируемость в глубину сложная (если business logic запросы на БД, то система slow)
- Изменения могут затронуть много слоёв

**Когда использовать:** Традиционные приложения (enterprise apps, CRM, ERP).

### Event-driven архитектура

**Как работает:** Вместо синхронных вызовов между компонентами, компоненты публикуют события, другие их слушают.

**Пример:**
```
Order Service: "OrderCreated" event
  ↓ (message queue: RabbitMQ, Kafka)
  ├→ Notification Service: отправить email
  ├→ Analytics Service: записать в analytics
  ├→ Inventory Service: уменьшить stock
  └→ Shipping Service: создать shipment
```

Если Notification Service down, остальные продолжают работать.

**Плюсы:**
- Слабая связанность (loose coupling)
- Легко добавить новый consumer события (не нужно менять Order Service)
- Асинхронность (можно ответить клиенту быстро, обработка event'ов в фоне)

**Минусы:**
- Сложнее отлаживать (когда что-то сломалось, нужно смотреть разные сервисы)
- Eventual consistency (заказ создан, но stock может обновиться через 5 минут)
- Сложнее гарантировать доставку события

**Когда использовать:** Real-time systems (notifications, analytics), высокие нагрузки.

## 3. Как архитектура влияет на roadmap

**Сценарий 1: Добавить экспорт в CSV**
- Монолит: 1 день разработки
- Микросервисы: 2-3 дня (нужно создать новый микросервис или расширить существующий, тестировать интеграцию)

**Сценарий 2: Масштабировать на 10M пользователей**
- Монолит: полная переписка архитектуры = 3-6 месяцев
- Микросервисы: добавить ещё инстансов, может быть оптимизация БД = 1-2 месяца

**Вывод для бизнеса:** Если планируем быстрый рост, нужна продумана архитектура.

## 4. Архитектурные решения, которые влияют на бизнес

### Выбор БД
- **Relational (PostgreSQL)**: ACID гарантии, но медленнее на больших volumes
- **NoSQL (MongoDB)**: Быстро масштабируется, но слабые гарантии

**Для финтеха** нужна PostgreSQL (транзакции критичны).
**Для analytics** — NoSQL может быть лучше.

### Кэширование
- Без кэша: 1000 рекветов/сек = 10 БД запросов/сек, потребуется мощный сервер БД
- С кэшем (Redis): 1000 реквестов/сек = 90 из кэша, 10 в БД

Кэш = значительное снижение затрат на инфраструктуру.

### Real-time vs Batch
- Real-time: Notification delivery в 1 секунду (требует event-driven архитектуры)
- Batch: Notification delivery раз в час (проще, но медленнее)

Выбор зависит от требований бизнеса.

## 5. Красные флаги архитектуры

Когда я вижу такое — алерм звонит:

1. **"Это работает, не трогай"** — архитектура не документирована, только в головах разработчиков
2. **Разработчик одного модуля не может развернуть его отдельно** — скорее всего, tight coupling
3. **Один bug в одном месте рушит всю систему** — нет fault tolerance
4. **Деплой занимает час и боятся нажать кнопку** — архитектура не поддерживает continuous deployment
5. **Каждая новая фича требует согласования с 5 разработчиками** — очень высокая связанность

## 6. Как я как BA взаимодействую с архитектурой

**На дизайне проекта (Planning)**
- Спрашиваю CTO: "Какова архитектура этого проекта? Монолит или микросервисы?"
- Понимаю, какие компоненты нужно разработать
- Оцениваю риски (если architecture новая, больше неопределённости)

**При добавлении требований (Refinement)**
- Спрашиваю: "Это требование повлияет на архитектуру? Нужно ли расширять APIs?"
- Если требование требует изменения архитектуры, это может добавить недели к проекту

**При выборе технологии (Tech Decision)**
- Обсуждаю с CTO альтернативы
- Учитываю не только технические плюсы/минусы, но и бизнес-результаты
- Пример: "Микросервисы дороже в развитии, но позволяют масштаивять независимо. Бизнес-ценность = скорость масштабирования вверх = выше выручка. Окупается за 6 месяцев."

**При оценке сроков (Planning)**
- Если архитектура хорошая, разработчики могут добавлять features быстрее
- Если архитектура плохая, нужно заложить больше буфера на рефакторинг и багфиксы

### Результат

Business Analyst, который понимает архитектуру:
- Даёт реальные оценки сроков
- Предлагает правильный roadmap
- Может объяснить, почему это требование займёт 3 недели, а не 2 дня
- Сотрудничает с техническими лидерами, а не просто передаёт требования
- Защищает интересы бизнеса (не позволит сделать что-то, что сломает систему)

Архитектура — это не деталь разработчиков. Это фундамент вашего бизнеса.

Что такое архитектура приложения?

Комментарии (1)

Архитектура приложения: определение и практическое применение

Основное определение

Архитектура с точки зрения Business Analyst

1. Почему это важно для бизнеса?

2. Основные типы архитектуры

Монолит (Monolithic)

Микросервисы (Microservices)

Слойная архитектура (Layered / N-tier)

Event-driven архитектура

3. Как архитектура влияет на roadmap

4. Архитектурные решения, которые влияют на бизнес

Выбор БД

Кэширование

Real-time vs Batch

5. Красные флаги архитектуры

6. Как я как BA взаимодействую с архитектурой

Результат