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

Ожидают услышать, что модель данных проектируется от бизнес-сценариев, а не от таблиц или кода. Важно, что учитываются целостность, связи, ограничения, валидация и удобство дальнейшего изменения. Также хорошо, если упомянуть разделение DTO, доменных сущностей и persistence-моделей.

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

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

В C# обычно разделяют:

Domain model — отражает бизнес-логику и правила;
Entity/ORM model — используется для хранения в БД;
DTO/ViewModel — используется для передачи данных наружу или в UI.

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

Например, в интернет-магазине можно выделить Order, OrderItem и Customer.
Order хранит заказ, OrderItem — позиции заказа, а Customer — данные клиента. В сервисном слое данные проверяются и собираются в доменную модель, затем сохраняются через ORM.

public class Order
{
    public Guid Id { get; set; }
    public Guid CustomerId { get; set; }
    public DateTime CreatedAt { get; set; }

    public List<OrderItem> Items { get; set; } = new();

    public decimal TotalAmount => Items.Sum(x => x.Price * x.Quantity);
}

public class OrderItem
{
    public Guid ProductId { get; set; }
    public string ProductName { get; set; } = string.Empty;
    public decimal Price { get; set; }
    public int Quantity { get; set; }
}

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

Order — это сущность заказа. В ней есть идентификатор, ссылка на клиента, дата создания и список позиций.
OrderItem описывает одну строку заказа: товар, цену и количество.
Свойство TotalAmount считается на лету, чтобы не хранить дублируемое и потенциально несогласованное значение.

Практически это работает так:

На вход приходит DTO из API.
Приложение валидирует данные.
DTO маппится в доменную модель Order.
Модель сохраняется через репозиторий или DbContext.
Для ответа наружу при необходимости используется отдельный DTO.

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

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

Какие методы и практике применяешь для работы с моделью данных в своих проектах?