灵活晋升/徽章模式

Question

让我们想象一下，像这样的系统，您运行，记录您的锻炼，然后当您完成锻炼上传到系统，并进行分析。根据分析，您可以获得徽章:5公里运行，10公里运行，3连续运行(3天)，早上运行等。我假设可以输入新的规则定义而不需要编码，或者至少不需要重新编译系统。可能类似的方法可以用来定义在电子商店促销的规则。你知道有什么经过战斗测试的模式可以在这里设计出一些有用的东西吗？

我在这里并不是想解决特定的问题，我只是展示了通用商业案例的用例，您可以映射到您想要的任何东西:套袋、促销、服药等等。

Answer 1

你可以设计一个规则引擎。例如，您可以从数据模型开始：

class BadgeRule { Condition, Name }
interface Condition { bool MatchesUser(User u); }
class DistanceCondition { MinimumDistance; ... }

badges = [
  { Name = "5km", Condition = DistanceCondition { MinimumDistance = 5'000 } }
  { Name = "10km", Condition = DistanceCondition { MinimumDistance = 10'000 } }
]

但是，当您想要设计更复杂的规则时，您可能需要做额外的开发工作，以便将这些信息提供给规则引擎。此外，您的规则引擎最终会变得如此复杂，以至于它只是一种临时编程语言，这也有可能出现在格林斯夫第十定律中。

相反，您可以将现有的脚本语言(例如JavaScript、Lua、Python)嵌入到应用程序中，允许将新规则定义为插件，而不必重新部署软件。这可能是相当合理和安全的，实际上(例如，考虑一个瓦斯沙箱)。但它要求您在脚本语言和内部数据模型之间创建合适的绑定。在控制对数据的访问并不重要的系统中，仅仅让插件定义自定义SQL查询可能是一种简单的方法。

许多系统不需要这种程度的可配置性。特别是，如果规则是由创建和运行软件的同一个组织定义的，那么修改和重新部署软件就更合适了。自从“DevOps”普及以来，软件开发社区现在已经有了让部署相当轻松的好主意。

让规则实现涉及编码也可以帮助新的徽章通过问答过程，以确保它的工作。可测试性通常在“低代码”系统或规则引擎中受到限制，在这些系统中，新规则可能必须在prod中进行测试。