Что такое жирная модель?

Жирная модель

Жирная модель (fat model) — это паттерн архитектуры приложения, в котором большая часть бизнес-логики сосредоточена в моделях данных, а слой представления (view) и контроллеры остаются максимально простыми. Это противоположность тощей модели (thin model), где логика разделена между разными слоями.

Характеристики жирной модели

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

• Логика находится в одном месте — её проще тестировать
• Переиспользование логики между разными частями приложения
• Модель становится основным источником правил бизнеса
• Упрощает разработку REST API — вся логика уже в модели

Недостатки:

• Модели становятся сложными и трудными для поддержки
• Нарушение принципа Single Responsibility Principle (SRP)
• Сложнее масштабировать приложение
• Модель смешивает разные уровни абстракции

Пример жирной модели

class User:
    def __init__(self, name: str, email: str):
        self.name = name
        self.email = email
    
    def validate_email(self) -> bool:
        """Валидация email"""
        return "@" in self.email and "." in self.email
    
    def send_welcome_email(self) -> None:
        """Отправка приветственного письма"""
        if self.validate_email():
            # Логика отправки
            print(f"Письмо отправлено на {self.email}")
    
    def calculate_discount(self, purchase_amount: float) -> float:
        """Расчёт скидки"""
        if purchase_amount > 1000:
            return purchase_amount * 0.1
        return 0
    
    def process_registration(self) -> bool:
        """Полная обработка регистрации"""
        if not self.validate_email():
            return False
        self.send_welcome_email()
        return True

Пример тощей модели (противоположность)

from dataclasses import dataclass

@dataclass
class User:
    """Модель содержит только данные"""
    name: str
    email: str

class EmailValidator:
    @staticmethod
    def validate(email: str) -> bool:
        return "@" in email and "." in email

class EmailService:
    @staticmethod
    def send_welcome(user: User) -> None:
        if EmailValidator.validate(user.email):
            print(f"Письмо отправлено на {user.email}")

class DiscountCalculator:
    @staticmethod
    def calculate(purchase_amount: float) -> float:
        if purchase_amount > 1000:
            return purchase_amount * 0.1
        return 0

class RegistrationService:
    def __init__(self, validator: EmailValidator, email_service: EmailService):
        self.validator = validator
        self.email_service = email_service
    
    def register(self, user: User) -> bool:
        if not self.validator.validate(user.email):
            return False
        self.email_service.send_welcome(user)
        return True

Баланс на практике

В реальных проектах используется сбалансированный подход:

• Модель содержит: валидацию, основные методы расчёта, работу с собственным состоянием
• Сервисы содержат: координацию нескольких моделей, интеграцию с внешними сервисами, бизнес-процессы
• Контроллеры содержат: обработку HTTP-запросов, преобразование данных

class User:
    """Модель с умеренным количеством логики"""
    def __init__(self, name: str, email: str):
        self.name = name
        self.email = email
    
    def is_valid(self) -> bool:
        """Только валидация своего состояния"""
        return "@" in self.email

class UserService:
    """Сервис координирует логику"""
    def __init__(self, email_service: EmailService):
        self.email_service = email_service
    
    def register(self, name: str, email: str) -> User:
        user = User(name, email)
        if not user.is_valid():
            raise ValueError("Invalid email")
        self.email_service.send_welcome(user)
        return user

Когда использовать жирную модель

• Для простых CRUD приложений с малым объёмом логики
• Прототипирование и MVP
• Когда нужна скорость разработки

Когда избегать

• Большие enterprise системы
• Когда логика повторяется в разных местах
• Когда нужна высокая тестируемость
• Микросервисная архитектура

В Python-сообществе чаще используется сбалансированный подход — модели содержат бизнес-логику, но сложная координация делегируется сервисам и использованным паттернам (Repository, Factory и т.д.).