应用于领域驱动设计原则的最佳实践？

Question

领域驱动设计有时会让人感到困惑，因为我对这种技术比较陌生，所以我想对那些目前困扰我的场景有一些答案。

这是一个使用DDD原则表示我的问题的简单图表。我的问题是关于聚合根，域验证和“做法”或最佳实践。

1. 在这种情况下，您如何实现一种计算用户撰写的评论数量的方法？它会成为“评论”中的一种方法吗？或者最好成为存储库中的方法（ReviewRepository）？
2. 如果需要，如何让其他实体访问评论？有这种情况，这是否意味着评论不再是“评论”聚合的一部分？
3. 如果评论与其他实体有组合关系怎么办？您将如何管理对该实体的访问？评论是否负责此实体或根？
4. 有关此型号的任何其他建议或事实？在设计模型时我应该采用哪些最佳实践？

感谢。

注意：答案必须是DDD原则

Review实体中有一点错误。 Add方法中的“Compte”是“Account”，应该是A而不是C.

Answer 1

  

在这种情况下，您将如何实现计算用户撰写的评论数量的方法？

责任属于审核。这是评论的总和。 Count是任何聚合的一流特征。

  

如果需要，我如何让其他实体访问评论？

评论可通过评论获取。评论是评论的集合。

  

如果评论与其他实体有组合关系怎么办？

如果没有具体和具体的例子，“如果”问题很难回答。毕竟，设计是由问题域驱动的，而不是随意的想法。

如果某个“其他”实体似乎也是评论的组合，您必须回到域专家并尝试确定真正责任所在的位置。

一对问题是“如果审核被删除，评论会发生什么？”并且“如果神秘'其他'被删除，评论会发生什么？”这有助于找到责任。