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

Question

域驱动设计有时会让人感到困惑，因为我对这项技术颇为陌生，所以我想针对那些正在困扰我的场景做一些解答。

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

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

谢谢。

注意：答案一定同胞DDD原则

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

Answer 1

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

责任归属于审查。这是一个评论汇总。 Count是任何聚合的头等功能。

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

评论通过审查可访问。评论是评论的汇总。

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

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

如果某些“其他”实体似乎也是评论的组成部分，则必须返回到域专家并尝试确定责任所在的位置。

一对问题是“如果评论被删除，评论会发生什么？”和“如果神秘的'其他'被删除，评论会发生什么？”这可以帮助找到责任。