Был ли у вас доменный проект или центральный слой в архитектуре

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

Понимаете ли вы, что такое доменный слой в .NET-решении и почему он ни от чего не зависит, или просто называли так папку с моделями. Следом просят показать, где в вашем решении жили бизнес-правила и как слой был отделён от EF Core.

Как отвечать

Опишите реальную структуру решения. Типичный вариант по Clean Architecture или луковой архитектуре:

• Domain: библиотека классов без ссылок на EF Core, ASP.NET Core и прочую инфраструктуру. Сущности с приватными сеттерами, инварианты проверяются в конструкторах и методах (order.AddItem(), order.Cancel()), объекты-значения как record, агрегаты, доменные события, интерфейсы вроде IOrderRepository;
• Application: сценарии использования, команды и запросы, валидация, DTO. Зависит только от Domain;
• Infrastructure: DbContext, реализации репозиториев, маппинг через IEntityTypeConfiguration<T>, чтобы детали EF не протекали в домен, клиенты внешних API;
• Web или API: контроллеры или minimal API, регистрация зависимостей в DI-контейнере.

Зависимости направлены внутрь: Infrastructure знает о Domain, наоборот нет. Хорошо, если скажете, как это соблюдали: архитектурные тесты на NetArchTest или ArchUnitNET валят сборку при запрещённой ссылке.

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

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

Называют доменом анемичные модели: классы только со свойствами, а вся логика в OrderService. Это тоже рабочий подход, но тогда не стоит говорить о DDD.

Держат в сущностях атрибуты маппинга [Table] и [Column] или ссылку на пакет Microsoft.EntityFrameworkCore. Центральный слой после этого зависит от схемы базы и ORM.

Строят обобщённый IRepository<T> поверх DbContext, который сам реализует паттерны Repository и Unit of Work. Получается лишний слой без выгоды, и в разговоре вас попросят объяснить, зачем он был нужен.