Что такое архитектурные паттерны?

Архитектурные паттерны: Структура приложения на макроуровне

Архитектурные паттерны — это высокоуровневые решения для организации структуры приложения, которые определяют как компоненты взаимодействуют между собой и как разделяется ответственность. Это отличается от design patterns, которые работают на уровне кода.

Отличие от Design Patterns

DESIGN PATTERNS (уровень класса/модуля)
- Singleton, Factory, Observer, Strategy
- Решают локальные проблемы
- Видны в коде

ARCHITECTURE PATTERNS (уровень приложения)
- Monolith, Microservices, Clean Architecture
- Определяют глобальную структуру
- Видны в структуре папок и deployment

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

1. Monolithic (Монолит)

Всё приложение в одном процессе.

┌─────────────────────────────────────────┐
│       Monolithic Application            │
│  ┌──────────────┐  ┌──────────────┐    │
│  │ User Module  │  │ Order Module  │    │
│  └──────────────┘  └──────────────┘    │
│  ┌──────────────┐  ┌──────────────┐    │
│  │ Payment      │  │ Inventory    │    │
│  └──────────────┘  └──────────────┘    │
│         ↓                ↓              │
│      Shared Database                   │
└─────────────────────────────────────────┘

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

• ✅ Простая разработка изначально
• ✅ Легко транзакции между модулями
• ✅ Проще мониторинг

Недостатки:

• ❌ Масштабирование — нельзя масштабировать отдельные модули
• ❌ Развёртывание — изменение в одном модуле требует перезагрузку всего
• ❌ Technology lock-in — все на одном стеке

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

Каждый сервис отвечает за одну business domain.

┌──────────────────────────────────────────────────────┐
│              API Gateway                             │
└──────────────┬───────────────────┬──────────────────┘
               │                   │
       ┌───────▼────────┐  ┌──────▼──────────┐
       │ User Service   │  │ Order Service   │
       │ DB: PostgreSQL │  │ DB: MongoDB     │
       └────────────────┘  └─────────────────┘
               │                   │
       ┌───────▼────────┐  ┌──────▼──────────┐
       │ Payment        │  │ Inventory       │
       │ Service        │  │ Service         │
       └────────────────┘  └─────────────────┘

Эти сервисы общаются через:
- REST/gRPC
- Message Queue (RabbitMQ, Kafka)
- Event Bus

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

• ✅ Независимое масштабирование
• ✅ Независимое развёртывание
• ✅ Разные tech stacks
• ✅ Fault isolation

Недостатки:

• ❌ Сложность в разработке
• ❌ Distributed transactions (очень сложно)
• ❌ Network latency
• ❌ Data consistency

3. Clean Architecture (Луковая архитектура)

Слои зависимостей направлены внутрь.

┌─────────────────────────────────────────────┐
│        Presentation Layer (Controllers)     │
└─────────────────────────────────────────────┘
           ↓
┌─────────────────────────────────────────────┐
│  Application Layer (Use Cases, Services)    │
└─────────────────────────────────────────────┘
           ↓
┌─────────────────────────────────────────────┐
│  Domain Layer (Entities, Business Logic)    │
└─────────────────────────────────────────────┘
           ↓
┌─────────────────────────────────────────────┐
│ Infrastructure (DB, External APIs, Caches)  │
└─────────────────────────────────────────────┘

Зависимости: Presentation → Application → Domain
Infrastructure зависит от Domain (через интерфейсы)

4. Hexagonal Architecture (Ports & Adapters)

Адаптеры позволяют менять внешние источники без изменения бизнес-логики.

┌──────────────────────────────────────────┐
│         Core Domain Logic                │
│  (interfaces: UserRepository, etc)       │
└──────────────────────────────────────────┘
        │           │           │
   ┌────▼──┐  ┌────▼──┐  ┌────▼──┐
   │ HTTP  │  │ GRPC  │  │Kafka  │
   │Adapter│  │Adapter│  │Adapter│
   └────┬──┘  └────┬──┘  └────┬──┘
        │          │          │
   ┌────▼──────────▼──────────▼──┐
   │  External Systems            │
   │ (REST API, DB, Message Bus)  │
   └────────────────────────────┘

Ключевая идея: Core business logic не знает о деталях HTTP, DB и т.д.

5. Event-Driven Architecture

Сервисы общаются через события.

┌────────────┐
│ User       │  создал юзера
│ Service    ├─────────────────┐
└────────────┘                  │
                         ┌──────▼──────┐
                         │ Event Bus   │
                         │ (Kafka)     │
                         └──────┬──────┘
                                │
                    ┌───────────┼───────────┐
                    │           │           │
            ┌───────▼──┐  ┌────▼──────┐  ┌▼──────────┐
            │Email     │  │ Welcome   │  │Analytics  │
            │Service   │  │ Service   │  │Service    │
            └──────────┘  └───────────┘  └───────────┘

6. Layered (N-Tier) Architecture

Традиционное деление на слои.

┌─────────────────────────────┐
│  Presentation Layer (JSP)   │
├─────────────────────────────┤
│  Business Logic Layer       │
├─────────────────────────────┤
│  Data Access Layer          │
├─────────────────────────────┤
│  Database                   │
└─────────────────────────────┘

Это то, что учат в большинстве курсов Java.

Как выбрать архитектурный паттерн?

Если ты стартап (MVP) → Monolith
Если масштабируешь (10+ инженеров) → Microservices или Modular Monolith
Если нужна гибкость (разные tech stacks) → Microservices
Если нужна надёжность (финансы) → Event-Driven + Clean Architecture
Если нужна простота → Layered

Практический пример: Java приложение

// CLEAN ARCHITECTURE СТРУКТУРА
src/
├── domain/              // Business logic (Database agnostic)
│   ├── User.java
│   └── UserRepository.java (interface)
│
├── application/         // Use cases, services
│   └── CreateUserUseCase.java
│
├── infrastructure/      // Implementations
│   ├── UserRepositoryJPA.java
│   └── UserRepositoryMongoDB.java
│
└── presentation/        // Controllers
    └── UserController.java

// Domain (не зависит от Spring, JPA и т.д.)
public interface UserRepository {
    void save(User user);
    User findById(String id);
}

// Infrastructure (зависит от Domain)
@Repository
public class UserRepositoryJPA implements UserRepository {
    @Autowired
    private JpaUserRepository jpaRepo;
    
    @Override
    public void save(User user) {
        jpaRepo.save(new UserEntity(user));
    }
}

// Application (зависит от Domain)
@Service
public class CreateUserUseCase {
    private final UserRepository repository;
    
    public CreateUserUseCase(UserRepository repository) {
        this.repository = repository;  // Inject interface, not implementation
    }
    
    public void execute(CreateUserRequest request) {
        User user = new User(request.getName(), request.getEmail());
        repository.save(user);
    }
}

// Presentation (зависит от Application)
@RestController
public class UserController {
    private final CreateUserUseCase createUserUseCase;
    
    @PostMapping("/users")
    public void createUser(@RequestBody CreateUserRequest request) {
        createUserUseCase.execute(request);
    }
}

Ключевые принципы

1. Dependency Inversion — зависимости направлены внутрь
2. Separation of Concerns — каждый слой одну ответственность
3. Testability — можно тестировать бизнес-логику без DB
4. Flexibility — легко менять реализацию (JPA ↔ MongoDB)

На собеседовании ожидают

• Что это макроуровневые decisions
• Отличие от design patterns
• Примеры (Monolith vs Microservices)
• Как выбирать в зависимости от requirements
• Понимание Clean Architecture или другого подхода, который используется в компании