Что хотят услышать интервьюеры:

Бизнес-правила не должны зависеть от базы данных, ORM или способа хранения. Логику предметной области выделяют в отдельный слой, а доступ к данным — в отдельный слой инфраструктуры. Такой подход упрощает тестирование, замену хранилища и поддержку кода.

Определение:

Разделение бизнес-правил и уровня хранения данных означает, что правила работы приложения описываются независимо от того, как и где данные сохраняются. Бизнес-логика отвечает за поведение системы: проверки, расчёты, статусы, ограничения. Слой хранения отвечает только за чтение, запись и загрузку данных.

Обычно это реализуют через архитектурные слои: доменная модель, сервисы, репозитории, адаптеры к БД. Важно, чтобы доменный код не содержал SQL, запросов к ORM и деталей конкретной СУБД.

Пример использования:

Например, в интернет-магазине правило «нельзя оформить заказ, если товара нет на складе» должно жить в сервисе или доменном объекте, а не в методе модели ORM.

from dataclasses import dataclass

@dataclass
class Product:
    id: int
    name: str
    stock: int

class ProductRepository:
    def get_by_id(self, product_id: int) -> Product:
        # Здесь был бы запрос к БД
        return Product(id=product_id, name="Keyboard", stock=3)

    def save(self, product: Product) -> None:
        # Здесь была бы запись в БД
        pass

class OrderService:
    def __init__(self, product_repository: ProductRepository):
        self.product_repository = product_repository

    def place_order(self, product_id: int, quantity: int) -> None:
        product = self.product_repository.get_by_id(product_id)

        if product.stock < quantity:
            raise ValueError("Недостаточно товара на складе")

        product.stock -= quantity
        self.product_repository.save(product)

Пояснение кода:

Код показывает разделение ответственности по шагам:

Product — это простая доменная сущность с данными о товаре.
ProductRepository скрывает детали хранения: приложение не знает, используется ли SQL, NoSQL или ORM.
OrderService содержит бизнес-правило: проверяет остаток и решает, можно ли оформить заказ.
Если правило изменится, например появится минимальный остаток или резервирование, менять нужно сервис, а не слой хранения.
Репозиторий можно подменить на мок в тестах, поэтому бизнес-логику легко проверять без базы данных.

Ключевые моменты:

Бизнес-логика не должна зависеть от БД, ORM и SQL.
Проверки, расчёты и правила предметной области выносятся в сервисы или доменную модель.
Доступ к данным инкапсулируется в репозиториях или DAO.
Такое разделение упрощает unit-тесты, так как бизнес-логику можно тестировать без БД.
Изменение хранилища не должно затрагивать бизнес-правила.
Чем меньше логики в моделях хранения, тем легче сопровождать приложение.

Каким образом вы разделяете бизнес-правила от уровня хранения данных в приложении?