涉及经常性付款和未来事件的困难建筑问题

时间:2010-11-05 10:26:33

标签: ruby-on-rails ruby design-patterns datetime architecture

2 个答案:

答案 0 :(得分:3)

是否可以应用银行使用的方案,您每天处理一次所有帐户操作? 每个对象都可能有一组(未来)操作,如冻结期,每天对象必须做出一个简单的决定,例如:“我今天应该过期吗?”

好的部分是,这种日常处理非常简单。另外一个奇怪的更新规则(如果你想要它们)很容易设计:“它是星期五吗?这是本月的最后一个吗?如果是,请标记我续订,增加一些金额到所需付款,或做任何事情”

每次询问对象时,动态计算状态将是非常昂贵的(在计算能力方面)。如果存储当前的“帐户”,则只需要在预测未来状态时进行更复杂的计算。

将其视为伪代码:

def process(day)
  raise "Already processed or missed a day" unless day == last_processed_day + 1

  check_expiration day
  check_frozen day
  check_anything day
  #...

  self.last_processed_day = day
  self.save!
end

响应:

  

具体来说,我想知道你的概念将如何处理我在原始问题中描述的经常性付款情况,以及我刚刚在Kris Robison的回答中留下的评论。如果我已经为特定购买设置了定期付款的时间表,并且在付款中间安排了冻结事件,那么付款时间表将保持不变,直到冻结日期变为当前日期为止。冻结的时间到了,付款会继续前进吗?

     

这对我来说可能是一种简化我的应用程序的好方法,但我想知道用户如何看待它。我如何向他们表明他们在安排冻结时所看到的付款时间表不再是准确的时间表,但一旦冻结就会改变?

“日常处理”方案可帮助您快速回答需要复杂计算的问题。

你有三个“群体”:当前状态(经常被问到),历史(几乎从不改变,相对很少被问到)和未来。

您的日常处理程序不仅限于更新“当前”状态。如果某个事件安排在处理日期,则该过程可能需要添加“历史记录”。

如果您的用户经常会询问有关未来的问题(正如您所说的那样),“处理”也可能会为这些问题创建一种缓存。例如:查找(计算)下一个付款日期,并将其写入帮助程序表(计划表)。

您需要做的主要事情是确定用户会问哪些问题,以及您是否能够即时计算答案,或者您需要准备好答案。

如果您询问当前的余额,在银行(当然会有所不同),他们可能会在一天开始时给您答案。 “更好”的银行会告诉你,你早上有X $,但现在还有Y $等待会计。

因此,如果您将冻结记录放入事件队列,则可以调用方法,该方法将立即更新计划。在日常处理程序中将会或可能会调用相同的程序(或非常相似的程序)。

答案 1 :(得分:1)

想到了几个问题:

  1. 冻结的时间可能不到一个月吗?
  2. 如果是,续订日期是否会改变?或者月份付款如何应用于部分月份?
  3. 这些会影响您的事件排队系统如何运作,但最终不会改变订阅付款的管理。

    解决订阅问题的一种方法是创建订阅付款的摊还表。如果他们每月支付一年的费用,则表格中列出了12笔付款。每周客户可能在同一表中有52笔付款。每次续订日期到来时,在检查冻结是否到位后,请应用下一笔付款。

    摊销表记录已进行的付款。如果帐户取消,则退还未付费的行。如果某个帐户根据您的事件队列冻结,则不会应用任何付款,并且该表格将保持静态,直到该帐户解冻为止。

    回复

    听起来你已经在摊还表中内置了续约日期的概念。我将分期付款表更多地用作队列,并保留订阅的下一个续订日期。

    如果续约日期是摊还表所固有的,那么是的,随着事情的进展做出改变会很复杂。但是,续订日期应仅影响您检查是否应用其他付款的日期。

    如果您在暂停订阅时保留部分付款,并且暂停时间可能是指定的时间段,则在分期付款表中使用持续时间值可让您将部分付款推回到队列中“信用“持续时间等于付款剩余时间的状态。这样,当帐户解冻时,首先应用部分信用,然后从剩余的持续时间计算下一个续订日期。

    此时使用某种形式的有序列表来保留付款顺序。如果出于客户服务原因,有人想要插入续订期的信用额度,它也会派上用场。