Какие знаешь декомпозиции?

Виды декомпозиции систем

Декомпозиция - это процесс разделения сложной системы на более мелкие, управляемые части. Это один из главных инструментов архитектуры и проектирования. Существует несколько подходов к декомпозиции.

1. Функциональная декомпозиция (Functional Decomposition)

Идея: Разделяем систему по функциям/операциям, которые она выполняет.

// Вместо одного большого класса:
public class MonolithicUserManager {
    public void createUser(String name) { /* ... */ }
    public void deleteUser(int id) { /* ... */ }
    public void sendEmail(String email) { /* ... */ }
    public void generateReport() { /* ... */ }
    public void backupDatabase() { /* ... */ }
}

// Делим по функциям:
public class UserService {
    public void createUser(String name) { /* ... */ }
    public void deleteUser(int id) { /* ... */ }
}

public class EmailService {
    public void sendEmail(String email, String message) { /* ... */ }
}

public class ReportService {
    public void generateReport() { /* ... */ }
}

public class BackupService {
    public void backupDatabase() { /* ... */ }
}

Плюсы:

• Логично и интуитивно
• Каждый класс отвечает за одно
• Легко добавлять новые функции

Минусы:

• Может привести к множеству классов
• Связи между функциями могут быть сложными
• Может быть трудно масштабировать

2. Объектно-ориентированная декомпозиция (Object-Oriented Decomposition)

Идея: Разделяем систему по объектам (сущностям), которые она моделирует.

// Моделируем реальные объекты:

public class User {
    private String name;
    private String email;
    
    public void create() { /* Пользователь создает сам себя */ }
    public void delete() { /* Пользователь удаляет сам себя */ }
    public void sendEmail(String message) { /* Пользователь может отправить сообщение */ }
}

public class Order {
    private User customer;
    private List<Item> items;
    
    public void create() { /* Заказ создает себя */ }
    public void cancel() { /* Заказ может отменить себя */ }
    public double calculateTotal() { /* Заказ может посчитать сумму */ }
}

public class Payment {
    private Order order;
    
    public void process() { /* Платеж обрабатывает себя */ }
    public void refund() { /* Платеж может вернуть деньги */ }
}

Плюсы:

• Легко понять (моделирует реальность)
• Класс содержит данные и методы для работы с ними (инкапсуляция)
• Масштабируемость

Минусы:

• Может быть трудно разделить ответственность
• Объекты могут стать толстыми (God Objects)

3. Послойная декомпозиция (Layered Decomposition)

Идея: Разделяем систему по слоям (layers), каждый слой отвечает за определённый аспект.

// Presentation Layer - UI, Controllers
@RestController
@RequestMapping("/users")
public class UserController {
    @Autowired
    private UserService userService;
    
    @PostMapping
    public ResponseEntity<?> createUser(@RequestBody CreateUserRequest request) {
        User user = userService.createUser(request.getName());
        return ResponseEntity.ok(user);
    }
}

// Application/Business Logic Layer - Services
@Service
public class UserService {
    @Autowired
    private UserRepository repository;
    
    public User createUser(String name) {
        User user = new User(name);
        return repository.save(user);
    }
}

// Data Access Layer - Repository, Database
@Repository
public interface UserRepository extends JpaRepository<User, Long> {
    User findByName(String name);
}

// Entity - Domain Model
@Entity
public class User {
    @Id
    private Long id;
    private String name;
}

Структура:

Presentation Layer (REST endpoints, Controllers)
        ↓
Application Layer (Services, Business logic)
        ↓
Domain Layer (Entities, Business rules)
        ↓
Infrastructure Layer (Database, Repositories)

Плюсы:

• Четкое разделение ответственности
• Легко тестировать (можно mock'ировать слои)
• Понятная архитектура
• Стандартный подход в индустрии

Минусы:

• Может быть много боilerplate кода
• Изменение в одном слое может повлиять на другой
• Может быть неэффективно при простых операциях

4. Модульная декомпозиция (Module Decomposition)

Идея: Разделяем систему по модулям, каждый модуль - независимый, переиспользуемый набор функциональности.

// auth-module/
public class AuthModule {
    public class AuthService {
        public Token authenticate(String username, String password) { /* ... */ }
    }
    public class PermissionService {
        public boolean hasPermission(User user, String action) { /* ... */ }
    }
}

// payment-module/
public class PaymentModule {
    public class PaymentService {
        public Receipt processPayment(Order order, Card card) { /* ... */ }
    }
    public class RefundService {
        public Receipt refund(Receipt receipt) { /* ... */ }
    }
}

// notification-module/
public class NotificationModule {
    public class EmailNotificationService {
        public void sendEmail(String to, String subject, String body) { /* ... */ }
    }
    public class SMSNotificationService {
        public void sendSMS(String phone, String message) { /* ... */ }
    }
}

// Main Application
public class MainApplication {
    public static void main(String[] args) {
        // Используем модули как черные ящики
        AuthModule authModule = new AuthModule();
        PaymentModule paymentModule = new PaymentModule();
        NotificationModule notificationModule = new NotificationModule();
        
        // Они независимы и могут переиспользоваться
    }
}

Плюсы:

• Модули независимы и переиспользуемы
• Легко распределить между командами
• Простота подмены реализаций
• Микросервисы часто используют этот подход

Минусы:

• Сложная интеграция между модулями
• Дублирование кода
• Сложнее синхронизировать версии

5. Доменная декомпозиция (Domain-Driven Decomposition)

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

// Домен: Пользователи
public class User {
    private String username;
    private String email;
    
    public void register(String username, String email) { /* ... */ }
}

public class UserRepository {
    public User findByUsername(String username) { /* ... */ }
}

public class UserService {
    public void registerNewUser(String username, String email) { /* ... */ }
}

// Домен: Заказы
public class Order {
    private User customer;
    private List<Item> items;
    private OrderStatus status;
    
    public void place() { /* ... */ }
    public void cancel() { /* ... */ }
}

public class OrderRepository {
    public Order findById(Long id) { /* ... */ }
}

public class OrderService {
    public void createOrder(User customer, List<Item> items) { /* ... */ }
}

// Домен: Платежи
public class Payment {
    private Order order;
    private PaymentStatus status;
    
    public void process(Card card) { /* ... */ }
    public void cancel() { /* ... */ }
}

public class PaymentRepository {
    public Payment findById(Long id) { /* ... */ }
}

public class PaymentService {
    public void processPayment(Order order, Card card) { /* ... */ }
}

Структура:

User Domain          Order Domain        Payment Domain
  ├─ User              ├─ Order           ├─ Payment
  ├─ UserRepository    ├─ OrderRepository ├─ PaymentRepository
  └─ UserService      └─ OrderService    └─ PaymentService

Плюсы:

• Выравнивание с бизнес-логикой
• Каждая команда может работать на одном домене
• Легче масштабировать отдельные домены
• Основа микросервисов

Минусы:

• Требует хорошего понимания бизнеса
• Интеграция между доменами может быть сложной
• Может быть оverkill для простых систем

6. Вертикальная (по особенностям) Декомпозиция

Идея: Разделяем систему по feature'ам (особенностям), каждая feature - отдельный набор функциональности от UI до БД.

// Feature: User Registration
registration/
  ├─ controller/
  │   └─ RegistrationController
  ├─ service/
  │   └─ RegistrationService
  ├─ repository/
  │   └─ RegistrationRepository
  ├─ model/
  │   ├─ RegistrationRequest
  │   └─ User
  └─ test/
      └─ RegistrationServiceTest

// Feature: Order Management
order-management/
  ├─ controller/
  │   └─ OrderController
  ├─ service/
  │   └─ OrderService
  ├─ repository/
  │   └─ OrderRepository
  ├─ model/
  │   └─ Order
  └─ test/
      └─ OrderServiceTest

// Feature: Payment Processing
payment/
  ├─ controller/
  │   └─ PaymentController
  ├─ service/
  │   └─ PaymentService
  ├─ repository/
  │   └─ PaymentRepository
  ├─ model/
  │   └─ Payment
  └─ test/
      └─ PaymentServiceTest

Плюсы:

• Feature находится в одном месте
• Легко добавлять/удалять features
• Упрощает параллельную разработку
• Лучше для микросервисов

Минусы:

• Может быть дублирование кода между features
• Сложнее обнаруживать общие части
• Требует хорошей координации

Сравнительная таблица

Рекомендации по выбору

1. Для монолита: Используй послойную + доменную декомпозицию
2. Для микросервисов: Используй доменную + модульную
3. Для быстрого прототипирования: Используй функциональную
4. Для сложных доменов: Используй доменную (DDD)
5. Для параллельной разработки: Используй по features

Заключение

Нет одного "правильного" способа декомпозиции - выбор зависит от:

• Типа приложения (монолит vs микросервисы)
• Размера команды (1 человек vs 10 команд)
• Сложности домена (простой CRUD vs сложная логика)
• Требования к масштабируемости
• Фаза проекта (MVP vs mature product)

Обычно успешные системы используют комбинацию нескольких подходов.