Какие архитектурные паттерны используются для разделения бизнес-логики и данных?

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

1. Service Layer (Слой сервисов): Содержит бизнес-логику. Координирует работу репозиториев и моделей, но не зависит от способа представления данных (например, HTTP-запросов).
2. Repository (Репозиторий): Абстрагирует доступ к источнику данных (БД, API). Предоставляет интерфейс для CRUD-операций, скрывая детали реализации (SQL, ORM).
3. Data Transfer Object (DTO): Простые объекты для передачи данных между слоями, не содержащие бизнес-логики.

Пример схемы взаимодействия:

# 1. Модель данных (например, Django ORM или SQLAlchemy)
class User:
    def __init__(self, name, email):
        self.name = name
        self.email = email

# 2. Репозиторий (работа с БД)
class UserRepository:
    def save(self, user: User):
        print(f"Сохранение пользователя {user.name} в БД...")
        # db.session.add(user); db.session.commit()

# 3. Сервис (бизнес-логика)
class UserService:
    def __init__(self, user_repository: UserRepository):
        self.repository = user_repository

    def register_user(self, name: str, email: str) -> User:
        if "@" not in email:
            raise ValueError("Некорректный email")
        new_user = User(name, email)
        self.repository.save(new_user)
        # Логика отправки email-подтверждения...
        return new_user

# 4. Использование (например, в контроллере FastAPI/Django View)
repo = UserRepository()
service = UserService(user_repository=repo)
try:
    user = service.register_user("John Doe", "john.doe@example.com")
except ValueError as e:
    print(e)

Такая структура позволяет легко заменять компоненты (например, перейти с PostgreSQL на MongoDB, изменив только репозиторий) и тестировать бизнес-логику в изоляции.