Как вы понимаете подход Domain Driven Design?

Что проверяют

Понимаете ли вы, что DDD в первую очередь про модель предметной области и её границы, а не про папки domain и infrastructure. Следом спрашивают, как это ложится на Django или SQLAlchemy и когда DDD не нужен.

Как отвечать

Разделите стратегическую и тактическую части. Стратегическая важнее:

• единый язык: термины бизнеса без перевода попадают в код. Если эксперт говорит «бронь», в коде нет Reservation в одном модуле и Order в другом;
• ограниченный контекст: граница, внутри которой модель однозначна. «Клиент» у продаж и у поддержки это разные модели, и это нормально;
• карта контекстов: как контексты связаны, включая антикоррупционный слой, который переводит чужую модель в свою;
• поддомены: core, куда стоит вкладываться, и типовые, которые можно взять готовыми.

Тактические паттерны:

• сущность: имеет идентичность, сравнивается по id;
• объект-значение: неизменяем, сравнивается по значению, удобно @dataclass(frozen=True): Money, Email;
• агрегат: кластер объектов с корнем, который охраняет инварианты. Одна транзакция меняет один агрегат, на другие ссылаются по id;
• репозиторий и Unit of Work: интерфейс в домене, реализация на SQLAlchemy в инфраструктуре;
• доменные события: связь агрегатов и контекстов без прямых вызовов.

Для Python уместно упомянуть книгу «Architecture Patterns with Python» (Percival, Gregory). Django ORM построен на Active Record, модель и хранение там слиты, и чистый домен требует отдельного слоя. В SQLAlchemy помогает императивный маппинг через registry.map_imperatively.

Если применяли DDD, расскажите про конкретный контекст и одно решение по границе. Если нет, скажите честно и объясните, где он оправдан.

Где спотыкаются

Сводят DDD к набору классов и папок. Без единого языка и границ контекстов это просто слоёная архитектура.

Строят анемичную модель: сущности без поведения, вся логика в сервисах. Инварианты при этом никто не охраняет.

Тащат DDD в простой CRUD. Для админки над тремя таблицами это лишние слои без выгоды.