涉及定期付款和未来事件的困难架构问题

Question

我正在寻找关于如何构建一个优雅的解决方案来解决这个有点棘手的问题的指导。虽然我使用 Ruby（和 Rails），但我认为我的问题很大程度上是一个架构问题，尽管我选择的语言显然会对涉及库等的建议产生影响，因此该语言仍然具有相关性。

无论如何，简而言之：我的应用程序包含代表会员资格的对象，属于健身设施的会员。会员资格包含一系列定期付款。有些会员资格在任期结束时自动续订，而另一些则不会。

例如，您的会员资格初始期限可能为一年，然后按月续订。在该应用程序中，创建此类会员资格会导致创建 12 笔定期付款。当最后一个月到期时，会员资格也随之到期。每日 cron 任务负责根据已完成的付款导致会员资格到期。如果成员资格设置为自动更新，则相同的 cron 任务将更新成员资格。

您的会员资格也可能没有初始期限，只是按月或按周运行。这些工作方式类似，只是减去了初始付款安排。

到目前为止，一切都很好。使事情变得复杂的是额外的要求：

• 管理员可以在特定的时间内“冻结”会员资格（将其搁置），之后它们会自动重新激活（例如，代表在一段时间内休假的人） ）。我可以选择立即冻结会员资格并稍后重新激活，或者我可以选择通过在未来的某个时间设置冻结日期以及重新激活日期来安排冻结（注意：总是有 重新激活日期，这使事情变得更容易一些）。

• 管理员可以立即取消会员资格，也可以设置将来取消会员资格。 （未来的取消功能尚未建立。）

• 管理员可以退还会员资格，这与取消会员资格类似，只是退还所有过去的付款

使这些问题难以处理的是对定期付款的影响。当您冻结会员资格时，定期付款必须在冻结期前后“延长”，这样代表冻结的时间段就不会被支付。这在概念上和程序上都很难处理。例如，付款可以延长不同的期限（即，每隔一周付款的人的每笔付款可以支付两周的会员资格），并且取消日期可以是付款涵盖期间内的任何日期。

对于冻结，我采取了成员资格对象包含一些日期的方法，即“freeze_on”和“thaw_on”来处理冻结期。然而，客户现在也希望将来取消，而且我注意到冻结功能存在一些错误，这让我相信我需要重新考虑我的方法。

我正在考虑进行更改，以便可以安排未来的事件，但不会影响应用程序的定期付款部分。这个想法是将特定事件排队。例如，未来的冻结将通过在特定日期排队冻结事件和随后日期的解冻事件来完成（从用户的角度来看，这两个事件将连接到单个“计划冻结”）。未来的取消也会以类似方式处理。

这种方法有一些好处，例如，如果您想取消将来的取消（这就是我所说的那种烦人、棘手的事情），您可以简单地从事件队列中删除预定的取消。

然而，我总有一种挥之不去的感觉，我可能只是从油锅里跳进了火里。我想知道是否有人可以就这个问题为我提供一些指导。对于此类问题，是否有可供我检查的设计模式或现有架构原则？

另外需要注意的是，具有预定期限的会员资格的定期付款（即不是每月自动续订）必须作为可以编辑（及时移动、价格调整）的数据库记录存在，因此使用时间表达式（如 Martin据我所知，福勒建议）不适合这个问题。我意识到我提出的事件队列解决方案不会向用户显示任何现有定期付款可能发生的更改，但我认为我可以接受这一点。

不是 scanlife 条形码，它是

多伦多的二维码，请给我们您的创意人员

编辑：回应下面的两个很好的建议（评论框不允许如此详细的信息）：

< strong>Kris Robison：

1. 是的，冻结期可以是任意长度，尽管实际上我认为少于两周的情况很少见。但任何解决方案都应该有效，无论期限长短。

2. 是的，续订日期发生变化 - 它会根据冻结时间的长短而提前。因此，如果冻结时间长达两周，付款就会提前两周。更棘手的是，在某些企业中，付款只能在特定日期提取 - 例如，某些俱乐部仅在每月 1 日和 15 日处理付款。因此，当日期被推迟时，对于这些俱乐部来说，他们必须“调整”到特定日期。

您能否更详细地解释为什么这些规则影响事件排队而不影响订阅付款的管理？

我对你的摊销表概念感兴趣。这基本上正是我已经建立的——每月付款的为期一年的会员资格创建了 12 个，每周创建了 52 个——每一个都有与之相关的金额、税收等，以及一个管理的状态机“待处理”、“已付款”、“失败”和“已退款”状态。

我遇到的问题是这张表如何响应事件。现在，如果您设置冻结，它会通过更改付款日期立即影响表格。在表格中间设置冻结，可以推迟付款。这听起来很有效，但实际上相当复杂且难以管理。您的摊销表想法将如何改善这种情况？

Arsen7：

这听起来像是我最初提出的事件队列。对我来说，很明显，您以前曾处理过类似的事情（您对处理日期的错误检查给我留下了深刻的印象，这是一个好主意，我打算尽快实施），所以我希望您能解释一下你的建议更详细一些。

具体来说，我想知道您的概念将如何处理我在最初的问题中以及我刚刚对克里斯·罗宾逊的答案留下的评论中描述的定期付款情况。如果我为特定购买设置了定期付款时间表，并且在付款中间安排了冻结事件，那么付款时间表是否会保持不变，直到冻结日期成为当前日期（此时）何时开始冻结并提前付款？

我觉得这可能是简化应用程序的好方法，但我想知道用户会如何看待它。我如何向他们表明，他们在安排冻结时查看的付款时间表不再是准确的时间表，而是在冻结发生后会发生变化？

Answer 1

是否可以采用银行使用的方案，即每天处理一次所有帐户操作？
每个对象都可能有一组（未来的）操作，例如冻结期，并且每天该对象都必须做出一个简单的决定，例如：“我今天是否应该过期？”

好的方面是，这样的日常处理非常容易编程。另外，一个奇怪的续订规则（如果您需要它们）设计起来很简单：“是星期五吗？这是本月的最后一个吗？如果是，请将我标记为续订，在所需付款中添加一些金额，或执行任何操作”。

每次询问对象时动态计算状态的成本非常高（就计算能力而言）。如果你存储当前的“账户”，当你想要预测未来的状态时，你只需要更复杂的计算。

将其视为伪代码：

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

响应：

具体来说，我想知道您的概念将如何处理我在最初的问题以及我刚刚对克里斯·罗宾逊的回答留下的评论中描述的定期付款情况。如果我为特定购买设置了定期付款时间表，并且在付款中间安排了冻结事件，那么付款时间表是否会保持不变，直到冻结日期成为当前日期（此时）何时开始冻结并继续付款？

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

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

您有三个“组”：当前状态（经常询问）、历史（几乎从未改变，询问相对较少）和未来。

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

如果您的用户经常询问有关未来的问题（正如您所说，他们会的），“处理”也可能会为这些问题创建一种缓存。例如：找到（计算）下一个付款日期，并将其写入辅助表（时间表）中。

您需要做的主要事情是决定用户将提出哪些问题，以及您是否能够即时计算答案还是需要准备答案。

在银行（当然，情况有所不同），如果您询问当前余额，他们可能会给出当天开始时的答案。 “更好”的银行会告诉你，早上你有X$，但现在还有Y$等待记账。

因此，如果您将冻结记录放入事件队列中，您可以调用一个方法，该方法将立即更新时间表。相同的过程（或非常相似的过程）将或可能在日常处理例程中被调用。

Answer 2

我想到了几个问题：

1. 冻结的时间可以少于一个月吗？
2. 如果是这样，续订日期会改变吗？或者如何将每月付款应用于部分月份？

这些会影响您的事件排队系统的工作方式，但最终不会改变订阅付款的管理。

解决订阅问题的一种方法是创建订阅付款摊销表。如果他们按月付款一年，则有十二笔付款会在表中排队。每周客户同一年的表中可能有 52 笔付款。每次续订日期到来时，检查冻结是否到位后，申请下一次付款。

摊销表记录了已支付的款项。如果帐户取消，未付款行将被退还。如果帐户根据您的事件队列冻结，则不会应用任何付款，并且表将保持静态，直到帐户解冻。

回复

听起来您在摊销表中内置了续订日期的概念。我更多地使用摊销表作为队列，并仅保留订阅的下一个续订日期。

如果续订日期是摊销表固有的，那么随着事情的进展进行更改会很复杂。但是，续订日期应该只影响您检查是否应用了另一笔付款的那一天。

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

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