Data structures 声誉引擎的设计

让我们想象一个社交网络，其中每个用户都可以通过（比如）授权从其他人那里获得声誉。因此，假设A和B最初的信誉度为1，当A委托给B时，A的信誉度为0，B的信誉度为2。 然后B可以委托给C，以此类推

此外-delagation有其作用域，作用域可以嵌套。因此，A可以代表所有主题的声誉，或者只代表编程，或者只代表c。他可以将编程任务委托给B，但也可以委托给C。这意味着最终的声誉取决于给定的范围

所以我们得到了一种有向图结构（可能是一棵树，但还不清楚循环是什么），我们需要遍历它来计算声誉

我试图用DDD原则来模拟这一点，但我不确定这里的聚合是什么

我认为委托树/图是一个候选，因为聚合是一致性的一个单位。然而，这意味着骨料将非常大。范围问题使其更加复杂，因为它使聚合边界变得不清晰。C#上的授权是否是编程授权的一部分

用户呢？作为一个集合，它必须存储对其他用户的引用（委托）。同样-给定用户属于哪个聚合

---

另一个问题是如何有效地计算声誉。我想在这种情况下，图形数据库比关系数据库更合适，但这是唯一的好答案吗？

中的根聚合意味着强制执行不变量。你告诉我们的授权规则是一组不变量。不知道您可能需要什么样的其他不变量，很难判断合适的根聚合是什么，但在我看来，简单地按照您提供的“用户”进行操作似乎是一个完美的根聚合，可以将所有委派规则作为不变量来执行。用户可能有一个或多个委派作用域，这些作用域本身可能是根聚合。根据委托规则，用户可以委托给另一个用户，而另一个用户又可以根据这些规则进行委托。这允许您强制执行所有不变量，并且在DDD规则下存储对（其他）用户的引用没有问题

不断询问您如何始终如一地实施特定于域的规则，您将发现您的根聚合

---

关于你的另一个问题：图形数据库似乎比关系数据库更好，但在信息有限的情况下很难判断。我建议您单独发布这个问题，并考虑关系数据库与图形数据库

为什么不使用graph db，少关注战术DDD模式？@YvesReynhout——你是在建议人们不先做任何设计就直接进入实现吗？这听起来真是太愚蠢了。如果你在我的评论中读到这一点，你就误解了我的话。较少关注面向对象友好的战术模式并采用图形范式可能是一种有益的探索。设计不是分析，设计探索也不是分析。