Я ищу руководство о том, как разработать элегантное решение для того, что стало немного сложной задачей.Хотя я использую Ruby (и Rails), я думаю, что моя проблема в значительной степени архитектурная, хотя мой выбор языка, очевидно, оказывает влияние с точки зрения предложений, связанных с библиотеками и т. Д., Поэтому язык остается актуальным.
В любом случае, в двух словах: мое приложение содержит объекты, представляющие членство, принадлежащие людям, которые являются членами фитнес-центров.Членство содержит серию периодических платежей.Некоторые членства автоматически возобновляются в конце срока их полномочий, в то время как другие этого не делают.
Так, например, у вас может быть членство на начальный период в один год, а затем возобновляется месяц за месяцем послетот.В приложении создание членства такого рода приводит к созданию 12 повторяющихся платежей.Когда истекает последний месяц, членство тоже.Ежедневное задание cron отвечает за прекращение членства на основе выполненных платежей.Если членство настроено на автоматическое продление, то же самое задание cron будет продлевать членство.
У вас также могут быть членства, которые не имеют начального срока и просто запускаются из месяца в месяц или из недели в неделю.Они работают аналогичным образом, за исключением начального графика платежей.
Пока все хорошо.Что усложняет ситуацию, так это дополнительные требования:
администраторы могут «заморозить» членство (приостановить их) на определенное время, после чего они автоматически активируются (например, чтобы представлять людей, которые идутуехать в отпуск на определенный период времени).Я могу заблокировать членство прямо сейчас и возобновить его позже, или я могу запланировать замораживание, установив дату замораживания в определенный момент в будущем, а также дату повторной активации (примечание: всегда дата повторной активации, что немного упрощает процесс.)
администраторы могут отменить членство либо прямо сейчас, либо установив отмену в будущем.(Будущие отмены еще не созданы.)
администраторы могут возместить членство, что аналогично отмене, за исключением того, что возвращаются все прошлые платежи.
С этим трудно справиться, это влияние на регулярные платежи.Когда вы замораживаете членство, повторяющиеся платежи должны «растягиваться» вокруг периода замораживания, чтобы период времени, который представляет замораживание, не оплачивался.С этим как концептуально, так и программно сложно справиться.Платежи, например, могут продлеваться на разные периоды (т. Е. Каждый платеж для того, кто платит каждую вторую неделю, платит за две недели членства), и дата отмены может быть где угодно в пределах периода, который покрывает платеж.
Для замораживания я использовал подход, в котором объект членства содержит несколько дат, а именно «freeze_on» и «thaw_on» для обработки периода замораживания.Тем не менее, клиент теперь хочет и в будущем отмены, и я заметил некоторые ошибки с функцией замораживания, что заставляет меня поверить, что мне нужно пересмотреть мой подход.
Я обдумываю изменения, чтобы будущие события моглибыть запланированным, но не влияют на часть повторяющихся платежей приложения.Идея состояла бы в том, чтобы поставить в очередь определенные события.Например, замораживание в будущем будет выполнено путем помещения в очередь события замораживания в конкретную дату и оттаивания в последующую дату (эти два события будут связаны в одно «запланированное замораживание» с точки зрения пользователя).Будущее аннулирование будет обрабатываться аналогично.
Этот подход имеет некоторые преимущества, например, если вы хотите отменить будущую аннулирование (это тот раздражающий, хитрый материал, о котором я говорю), вы можете простоудалить запланированную отмену из очереди событий.
Однако у меня есть ноющее чувство, что я могу просто прыгнуть со сковороды в огонь.Мне интересно, может ли кто-нибудь дать мне руководство по этому вопросу.Существуют ли шаблоны проектирования или существующие архитектурные принципы для решения такого рода проблем, которые я могу исследовать?
Еще одна вещь, на которую следует обратить внимание, заключается в том, что регулярные платежи за членство с запланированными сроками (то есть без ежемесячного автоматического продления) должнысуществуют как записи базы данных, которые можно редактировать (перемещать во времени, корректировать цену), поэтому использование временных выражений (как предлагает Мартин Фаулер) не подходит для этой проблемы, насколько мне известно.Я понимаю, что мое предлагаемое решение очереди событий не будет отображать пользователю изменения, которые могут произойти с любыми существующими повторяющимися платежами, но я думаю, что могу с этим смириться.
не штрих-код сканирования, этоqr код
Торонто, дайте нам своих творческих людей
Редактировать: Чтобы ответить на два замечательных предложения ниже (в полях для комментариев практически отсутствует уровень детализации)):
Крис Робисон:
Да, период замораживания может быть произвольной продолжительности, хотя на практике я предполагаю, что это будет редкоэто должно быть меньше двух недель.Но любое решение должно работать независимо от продолжительности периода.
Да, дата продления меняется - она продвигается вперед на длину замораживания.Таким образом, если замораживание длится две недели, оно продвигает платеж на две недели вперед.Чтобы сделать вещи особенно сложными, в некоторых компаниях платежи могут быть сняты только в определенные даты - например, некоторые клубы обрабатывают платежи только 1-го и 15-го числа каждого месяца.Поэтому, когда даты переносятся, для этих клубов им приходится «привязываться» к определенной дате.
Можете ли вы объяснить более подробно, почему эти правила влияют на организацию событий, а не на управлениеоплата подписки?
Меня интересует ваша концепция таблицы амортизации.Это в основном именно то, что я уже построил - годичное членство с ежемесячными платежами создает 12, а еженедельно - 52 - и у каждого из них есть сумма, налог и т. Д., Связанные с ними, наряду с государственным аппаратом, который управляетСостояния "в ожидании", "оплачено", "не выполнено" и "возмещено".
Часть, с которой я борюсь, - это реакция этой таблицы на события.Прямо сейчас, если вы установите замораживание, это немедленно повлияет на таблицу, изменив даты платежей.Установите замораживание в середине таблицы, и это подтолкнет платежи вперед.Это звучит эффективно, но на самом деле это довольно сложно и сложно управлять.Как ваша идея таблицы амортизации может улучшить эту ситуацию?
Arsen7:
Это похоже на очередь событий, которую я предложил изначально.Мне кажется очевидным, что вы работали с такими вещами раньше (я был впечатлен вашей проверкой ошибок на дату обработки, это отличная идея, и я собираюсь реализовать ее как можно скорее), поэтому я надеюсь, что вы сможете объяснитьВаше предложение чуть более подробно.
В частности, мне интересно, как ваша концепция справится с ситуацией с повторяющимися платежами, которую я описал в своем первоначальном вопросе и в комментарии, который я только что оставил на Крис Робисон?ответ.Если бы я настроил график повторяющихся платежей для данной покупки, а событие замораживания запланировано прямо в середине платежей, будет ли график платежей оставаться неизменным до тех пор, пока дата замораживания не станет текущей датой, в которуюВ какое время будет введено замораживание, и платежи будут продвигаться вперед?
Мне кажется, что это отличный способ упростить мое приложение, но мне интересно, как пользователи это воспримут.Как бы я им указал, что график платежей, который они просматривали, когда было запланировано замораживание, больше не является точным графиком, но изменится, когда произойдет замораживание?