Дискриминаторное поле и моделирование данных - PullRequest
Новая
       34

Дискриминаторное поле и моделирование данных

0 голосов
/ 29 октября 2018

У меня следующий случай.

Резервирование, это резервирование может быть отменено, оно может быть вновь создано, может быть подтверждено, что оно может быть отклонено.

Возможны разные причины отмены. Допустим, резервирование истекло или, возможно, оно не было обработано в течение определенного периода времени или по какой-либо другой причине.

Для подтверждения бронирования необходимо выполнить несколько суб-транзакций. Это означает, что в самом Подтверждении есть поток. Решение, с которым пришла моя команда, - это своего рода рабочий стол с различными статусами. Что хорошо. Я почувствовал необходимость однозначно идентифицировать состояние резервирования, объявив поле ReservationStatus, которое отображает определенные варианты статусов, которые уже определены в таблице. В этом случае статус бронирования будет НОВЫЙ, ПОДТВЕРЖДЕН, ОТМЕНЕН, ОТКЛОНЕН. Каждое состояние будет отображать определенные варианты статусов в рабочей таблице.

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

Как я могу на самом деле подтвердить, что у нас должен быть такой столбец, в котором, по-видимому, аргументов, которые я уже упоминал, было недостаточно, и глубоко внутри я знаю, что я прав:)?

1 Ответ

0 голосов
/ 30 октября 2018

Хотел, чтобы это был комментарий, но он вышел слишком долго, так что вот так.

@ AlexandarPetrov Я бы добавил следующие вопросы:

  • Все ли статусы конкретно представляют каждое государство, которое может иметь резервация?
  • Существуют ли четкие правила для всех путей миграции статуса? Например, Просрочено -> ПОДТВЕРЖДЕНО и пр.
  • Вам нужно смоделировать изменения состояния? И это конечный автомат?

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

Дополнительно: Мне кажется, что Event Sourcing и CQRS могли бы хорошо подойти ко всем этим бронированиям. Особенно имея в виду сложные потоки, которые вы упоминаете. Тогда переходы будут применяемыми событиями, а статусы - простым способом раскрытия состояния. Отдельное отслеживание изменений статуса также не потребуется, поскольку поток событий содержит все исторические данные.

Наконец:

Как я могу на самом деле подтвердить, что у нас должен быть такой столбец, в котором, по-видимому, аргументов, которые я уже упоминал, было недостаточно, и глубоко внутри я знаю, что я прав:)?

Ну, в конце концов, вы всегда можете опустить ногу и взять на себя ответственность. И если это окажется неправильным решением вовремя - снимите с себя ответственность и признайте ошибку.

...