В чем разница между двухзвенной и трехзвенной архитектурой?

В чем разница между двухзвенной и трехзвенной архитектурой

Это фундаментальные архитектурные паттерны, которые влияют на тестирование. Тестировал оба подхода на разных проектах.

Определения

2-Tier Architecture (Двухзвенная)

Структура:

[Client Layer] ←→ [Database]

Client: Desktop App / Web App
Database: MySQL, PostgreSQL, Oracle

Все бизнес-логика либо в client, либо в database

3-Tier Architecture (Трехзвенная)

Структура:

[Client Layer] ←→ [Server/Application] ←→ [Database]

Client: Web UI, Mobile App
Server: API, Business Logic (Node.js, Python, Java)
Database: MySQL, PostgreSQL, Oracle

Звено 1: Presentation (что видит пользователь)
Звено 2: Application (бизнес-логика)
Звено 3: Data (хранилище)

Детальное сравнение

2-Tier Architecture

Архитектура

Client App
├─ UI (Forms)
├─ Business Logic
├─ Validation
└─ Database Connection
      ↓
   Database
   ├─ Tables
   ├─ Stored Procedures
   └─ Data

Примеры

• Desktop application (Visual Basic, Delphi)
• Legacy systems
• Small internal applications
• Direct database connections from client

Как выглядит

Desktop App написан на VB.NET:
- User fills form
- Click "Save"
- Direct SQL to database
- UPDATE users SET name = 'John' WHERE id = 1;
- Database updated
- User sees success

Нет промежуточного server

3-Tier Architecture

Архитектура

Client Layer (Presentation)
├─ HTML/CSS/JavaScript
├─ UI Components
├─ Form Handling
└─ API Calls
      ↓
Application Layer (Business Logic)
├─ REST API endpoints
├─ Business logic
├─ Validation
├─ Authentication
├─ Authorization
└─ Data Processing
      ↓
Data Layer (Persistence)
├─ Database
├─ ORM models
├─ Queries
└─ Data Access

Примеры

• Modern web apps (Facebook, Netflix)
• Microservices
• Cloud applications
• API-based systems

Как выглядит

Modern Web App:

Client (React):
- User fills form
- Click "Save"
- Sends POST /api/users {name: 'John'}

Server (Node.js):
- Receives request
- Validates data
- Checks permissions
- Processes business logic
- Executes database query
- Returns response

Database (PostgreSQL):
- Updates record
- Returns confirmation

Client:
- Receives response
- Updates UI
- User sees success

Нет прямого соединения между Client и Database

При тестировании (мой подход)

Тестирование 2-Tier Architecture

Вызовы при тестировании:

1. No API to test separately
   - Нельзя тестировать API independently
   - Нужно тестировать через UI
   - Slow testing

2. Database directly exposed
   - Risky from security perspective
   - Can bypass business logic
   - Hard to validate

3. Limited automation
   - Difficult to automate (depends on UI framework)
   - Slow execution
   - Brittle tests

4. No load testing
   - Difficult to scale
   - Performance issues
   - Not designed for many users

Как я тестирую:

1. UI Testing (manual mostly)
   - Open app
   - Fill form
   - Submit
   - Check database directly

2. Database Testing
   - Connect directly to database
   - Verify data integrity
   - Check triggers/procedures

3. Performance
   - Limited options
   - Usually client machine is bottleneck

Тестирование 3-Tier Architecture

Преимущества при тестировании:

1. Can test API independently
   - API tests (unit + integration)
   - Mocking
   - Contract testing
   - Very fast

2. Can test UI separately
   - Mock API responses
   - Test error states
   - Test loading states
   - No database needed

3. Can test business logic independently
   - Unit tests for logic
   - Edge cases
   - Performance of algorithms

4. Easy to automate
   - API automation
   - UI automation (against mocked API)
   - Database automation
   - Load testing

Как я тестирую:

Pyramid of tests:

     E2E Tests
    (10%, slow)
   ┌─────────┐
   │ Browser │ Full flow
   │ API     │ UI + API + DB
   └─────────┘
   Integration Tests
    (30%, medium)
   ┌─────────┐
   │ API     │ Multiple layers
   │ Database│ No UI
   └─────────┘
   Unit Tests
   (60%, fast)
   ┌─────────┐
   │Business │ Single function
   │Logic    │ No DB, no API
   └─────────┘

Практический пример: Payment system

2-Tier Implementation

Client (VB.NET Desktop App)
- User fills payment form
- Direct database connection:
  "INSERT INTO payments VALUES (...)"
  "UPDATE accounts SET balance = balance - $100"

Database (MSSQL)
- Tables
- Triggers for validation

Testing:
- Open app
- Manual testing
- Check database with SQL queries
- Very slow (each test is manual)
- Hard to automate

3-Tier Implementation

Client (React Web)
- User fills payment form
- POST /api/payments {amount: 100}

Server (Node.js + Express)
- POST /api/payments endpoint
- Validate amount
- Check user balance
- Check fraud
- Create transaction
- UPDATE user balance
- Return response

Database (PostgreSQL)
- Execute queries
- Return results

Testing:
1. Unit test validation logic
   def test_validate_amount():
       assert validate(100) == True
       assert validate(-50) == False

2. Unit test fraud detection
   def test_fraud_detection():
       assert is_fraud(1000000) == True

3. Integration test payment flow
   POST /api/payments → database check → verify balance

4. E2E test full flow
   Browser → fill form → click submit → see confirmation

5. API test
   curl -X POST /api/payments -d {amount: 100}

6. Load test
   1000 simultaneous payments

Таблица сравнения

Когда использовать что

2-Tier подходит для

✓ Small internal tools (< 10 users)
✓ Desktop applications
✓ Legacy systems
✓ Very simple CRUD apps
✓ Educational purposes
✓ One-off scripts

❌ Modern web apps
❌ Mobile apps
❌ High-traffic systems
❌ Complex business logic

3-Tier подходит для

✓ Web applications
✓ Mobile applications
✓ Cloud systems
✓ Microservices
✓ High-traffic systems
✓ Complex business logic
✓ Multi-user systems
✓ Enterprise applications

✓ 99% of modern applications

Мой опыт

2-Tier (Early career)

Проект: Legacy VB.NET application
Years: First 2 years

Тестирование:
- Manual testing only
- Very slow
- Difficult to find bugs
- Regression testing nightmare

Вывод: 2-Tier тяжело тестировать

3-Tier (Modern career)

Проекты: Web apps, APIs, Mobile
Years: Last 8+ years

Тестирование:
- Automated tests
- Fast feedback
- Easy to find bugs early
- Good test coverage possible

Вывод: 3-Tier much better for testing

Migration from 2-Tier to 3-Tier

Старая система (2-Tier):
- Desktop app with database connection
- 50 users
- Growing to 500 users needed

Миграция:
1. Extract business logic from app
2. Create API server
3. Modernize UI (web, mobile)
4. Database stays mostly same
5. Add proper testing

Результат:
- Can handle 500 users
- Can test efficiently
- Can add features faster
- Can scale horizontally

Modern variations

N-Tier (расширение 3-Tier)

Client ↔ API Gateway ↔ Service 1 ↔ Database 1
         ↕ ↕ ↕         Service 2 ↔ Database 2
         ↕ ↕ ↕         Service 3 ↔ Cache
         ↕ ↕ ↕         Queue
         ↕ ↕ ↕         Message Broker
         
Звено 1: Presentation (Web, Mobile)
Звено 2: API Gateway
Звено 3-N: Microservices
Звено N+1: Data (Multiple DBs, caches)

Serverless (Modern approach)

Client (Web/Mobile) ↔ API Gateway ↔ Lambda Functions ↔ Database
                                  ↕ DynamoDB
                                  ↕ S3
                                  ↕ SQS

No server to manage
Auto-scaling
Pay per execution

Conclusion

2-Tier vs 3-Tier is about system architecture.

2-Tier:
- Old approach
- Limited scalability
- Hard to test
- Hard to maintain

3-Tier:
- Modern standard
- Scalable
- Testable
- Maintainable

As QA: 3-Tier is much easier to work with
- Can write efficient automated tests
- Can test layers independently
- Can achieve high coverage
- Can find bugs early

Мой опыт показал: современные системы должны быть 3-Tier (или N-Tier). Это обеспечивает качество, масштабируемость и тестируемость.