Вредные советы. Храните статусы в базе данных Заказ. Такая привычная сущность в БД. Так хочется закинуть в админку статусы с выбором: выполнен, оплачен, подтвержден и т.д. Если «повезет», то таких статусов может стать 10, 20, 30… Статусы — это же так здорово и необходимо! ❗️Что получите: – Никто не разберется в десятках статусов и они будут указываться рандомно; – Поломку механизмов фильтрации данных по статусам, потому что см. пункт выше; – Каждое значимое изменение статусной модели будет требовать недели для отладки дата миграций вашей продовой БД; – Рефакторинг заблокирован, а костыли внутри проекта множатся в геометрической прогрессии. ✍️ Пример из жизни Интегрировали платежную систему BetaTransfer в один из сайтов. 20 статусов у платежа в документации. Через 4 месяца эксплуатации узнали о 21-ом, которого не было в доке и техподдержка о нем тоже не знала. В общем товарищи накопили тот самый «балласт» статусной модели и потеряли контроль над ситуацией. 📌 Как дойти до жизни такой: разработать статусную модель для объектов БД на старте, развивать проект долго, добавлять новые статусы под потребности бизнеса, не удаляя старые. ❓Может просто статусная модель неправильно была выбрана? Нет, ее в принципе нельзя сделать раз и навсегда в отличии от схемы данных, если она отражает предметную область (см. пост про DDD). ❓А можно удалить ненужные статусы? На них завязан старый код. Удалите — логика рассыплется как карточных домик. ❗️Статусы не являются частью предметной области, т.е. не существуют в реальности. Статусы зависят от контекста и привязаны не к объекту, а к связке Роль — Объект — Процесс. Менеджеру и Клиенту нужны разные статусы одного и того же заказа. Менеджеру нужны разные статусы заказа на разных этапах обработки. Если Меняется структура команды, меняются бизнес-процессы → меняется набор необходимых статусов и завязанный на них код рассыпается. Если статусы есть в API — тем хуже. На них завязаны интеграции внешних сервисов и менять их совсем больно. ✍️ Как по-другому: — Использовать и хранить в БД простые поля, привязанные к конкретным событиям: дата оплаты заказа, флаг заказ подтвержден или дата подтверждения заказа, дата доставки заказа и т.д.. Эти свойства существуют в реальности и они не изменятся со временем. Дата оплаты останется датой оплаты. — Вынести статусы из слоя данных в слой представления, т.е. в фронтенд или хотя бы во вьюхи. Для каждого интерфейса у объекта вычислять нужные статусы на основе атомарных полей. — Перестать воспринимать статус как строковый литерал: «выполнен», «доставлен». Важна не строка, а алгоритм вычисления. Т.е. статус на самом деле — это формула, а не сама строка. В итоге у вас могут появиться в интерфейсе (не в БД!) сложносоставные статусы вроде «одобрен вчера», «рекомендация Юли» и т.д.