领域驱动程序设计中的规则引擎(以速率限制器为例)

Question

将规则引擎集成到域驱动程序设计中的好方法是什么？举个例子:如果我有一个通用的速率限制服务，那么

• 资源(广告、机器等)，具有属性(“类别”、“所有者”等)
• 事件(广告视图、广告点击等)。每个事件都有一个关联的用户和资源(用户X对事件Y采取行动)
• 限制:例如，“最多每天5个娱乐广告”，或“显示广告X最多2次/小时”，域名比这更丰富，但这应该是足够的例子。

似乎有三个聚合:资源，事件，限制。然而，评估用户的限制要求收集所有(A)用户执行的事件，(b)所有资源，(c)所有限制，然后评估规则。因此，这个“规则引擎”组件需要维护关于所有聚合的知识。

设计它的一种方法是为每个请求/用户设置一个规则引擎"Saga“，该引擎收集聚合中的所有信息并对规则进行评估。有人能建议另一个设计吗？

我正在使用Akka，所以上面的设计很好地满足了每个演员的要求。

Answer 1

另一种方法是让您的“规则引擎”不了解任何特定的聚合，而是保持所有数据相关。

您可以将所需的“参数”传递给规则引擎，以计算给定的“表达式”或“方法”的排序。例如：

方法：“速率限制器”参数：

• "AdClickCount"：10
• “类别”：“袜子”
• 等。

规则引擎会让数据返回所需的响应。

这些是泛泛的笔触。我为一家保险公司实现了类似的方法，根据与各种产品相关的许多规则来确定保费。

我正在开发一个开源版本，但是我没有足够的时间来完成它，但是可能有一些想法：https://github.com/Shuttle/Shuttle.Abacus。

Answer 2

假设您有一个应用程序，并且它需要有速率限制：

速率限制应该被看作是另一个有限制的上下文。它可以有两个方面：

• 管理部分，其中添加、编辑和删除资源和规则，以及
• 验证部分，其中操作被接受(以及它们的计数器递增)或被拒绝；对于这两个部分，您都可以包括解释性消息，即RetryAfter: 10 seconds或Remaining: 99。

验证这些限制取决于您的架构。例如，如果您使用API网关和微服务，那么对于每个动作(ad view、ad click)，API网关将检查请求和限制速率的微服务。

我不能给你一个一般的答案，这取决于每个用例。