Какие атрибуты должны быть в модели сделки

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

Умеете ли вы проектировать модель от бизнес-процесса, а не выписывать поля по памяти. Хороший знак, если первым делом вы спросите, о какой сделке речь: продажа в CRM, кредит в банке или сделка на бирже. Следом обычно просят показать жизненный цикл статусов или связи с другими сущностями.

Как отвечать

Уточните домен и дальше опишите поля группами:

• идентификация: внутренний ID и внешний номер (номер договора, номер во внешней системе), это разные вещи;
• участники: ссылки на контрагентов и ответственного менеджера по ID, а не копии их реквизитов в строке сделки;
• деньги: сумма в decimal или в минимальных единицах плюс код валюты по ISO 4217, для многовалютных сделок ещё курс и дата курса;
• даты: создание, подписание, дата исполнения или расчётов, плановое и фактическое закрытие. Отдельно зафиксируйте, в каком часовом поясе хранится время;
• тип и статус: справочник типов и конечный набор статусов с разрешёнными переходами, лучше нарисовать диаграмму состояний;
• условия: ставка, срок, график платежей, штрафы. Если условий много, это отдельная сущность, и у сделки может быть несколько версий условий;
• состав: позиции сделки (товары, услуги, транши) отдельной таблицей;
• аудит: кто и когда создал и менял, история статусов, признак мягкого удаления;
• документы: ссылки на договор и приложения в хранилище файлов.

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

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

Отвечают списком полей без вопроса о домене. Модели сделки в CRM и в казначействе банка отличаются почти полностью.

Хранят сумму во float и без валюты. Ошибки округления и путаница рублей с долларами всплывут в первой же сверке.

Делают статус свободным текстом и перезаписывают его без истории. Потом невозможно ответить, сколько сделок застряло на согласовании и сколько дней они там провели.