我正在为一本杂志开发一个网络应用程序,该应用程序允许用户在线登录和更新他们的订阅。这些订阅是根据一组规则续订的,我想就如何设置这些规则获得一些想法/建议。
此 Web 应用程序与具有订阅者数据的外部(第三方)系统交互。当订阅者登录时,Web 应用程序会从这个第三方系统中获取大量信息,包括一个称为“订阅定义 ID”的数字,它(表面上)表示订阅者拥有的订阅类型。这种订阅类型可能已经过时了几年,因此 Web 应用程序包含一组“订单规范”(存储在数据库中),其中包含当前订阅选项以及当前费率等信息(因此价格可以在订购单上显示给用户)。
我目前的想法是创建一个订阅定义 ID 表,该表映射到给定订阅定义 ID 更新到的订单规范。例如,订阅定义 ID 可能表示十年前的 1 年订阅,当时的价格为 39.99 美元;在数据库中,这将映射到当前订单规格,当前价格为 59.99 美元。
这在理论上工作得很好,但像往常一样,有一个问题。当年设置订阅定义 ID 时,它们并不总是唯一的。特别是,一个订阅定义 ID 具有完全不同的行为,具体取决于上下文。此订阅定义 ID 用于 1 年订阅和 1 年折扣礼品订阅。因此,给定此订阅定义 ID,可能会发生许多事情:
- 如果是 1 年订阅,他将使用(当前)1 年订阅进行续订。
- 如果它是 1 年折扣礼品订阅并且订阅者没有续订任何其他订阅,它将作为(当前)1 年全价礼品订阅续订。
- 如果它是 1 年折扣礼品订阅并且订阅者正在续订其他订阅,则它将作为(当前)1 年折扣礼品订阅进行续订。
我不确定如何在数据库中概括这一点,特别是因为这种复杂情况只发生在一条记录上。我基本上需要一种方法来对上述逻辑进行建模,该方法也可以处理非特殊情况的记录。我总是可以在代码中执行此操作,但我不愿意将所有这些业务逻辑放在代码本身中(尤其是在将来出现问题的情况下,使用其他订阅定义 ID)。
对这种数据和逻辑规则组合进行建模的最佳方法是什么?