领域驱动设计原则中应用的最佳实践？
领域驱动设计有时确实令人困惑，因为我对这项技术相当陌生，所以我想得到一些关于当前困扰我的场景的答案。
这是一个使用 DDD 原则来表示我的问题的简单图表。我的问题是关于聚合根、域验证和“方法”或最佳实践。
- 在这种情况下，您将如何实现一种方法来计算用户撰写的评论数量？这是“审查”中的方法吗？或者最好是成为存储库（ReviewRepository）中的方法？
- 如果其他实体需要的话，如何让他们访问评论？出现这种情况，是否意味着评论不再是“评论”聚合的一部分？
- 如果评论与其他实体有组合关系怎么办？您将如何管理对该实体的访问？评论是由该实体还是根负责？
- 关于这个模型还有其他建议或事实吗？设计模型时我应该遵循哪些最佳实践？
谢谢。
注意：答案必须符合 DDD 原则
Review 实体中存在一点错误。 Add方法中的“Compte”是“Account”，应该是A而不是C。
Domain Driven Design can be really confusing at times and since I am rather new to this technique I would like to have some answers regarding those scenarios that are currently bugging me.
Here a simple diagram to represent my question using DDD principles. My question is about aggregate roots, domain validation and "ways to do" or best practices.
- In this scenario, how would you implement a way to count the number of comments written by a user? Would it be a method in "Review"? Or would it be best to be a method in a repository (ReviewRepository)?
- How do I make other entities access comments if they need to? Having this scenario, does that mean that Comment isn't part anymore of the "Review" aggregates?
- What if comment have a composition relationship with some other entity? How would you manage the access to that entity? Is comment responsible of this entity or the root?
- Any other suggestions or facts regarding this model? Any best practices I should fellow when designing a model?
Thanks.
NOTE: The answer must fellow DDD principles
There a little error in the Review entity. "Compte" in the Add method is "Account" and should be A instead of C.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
责任属于审查。这是评论的汇总。计数是任何聚合的首要特征。
可通过评论访问评论。评论是评论的集合。
如果没有具体的例子，“假设”问题很难回答。毕竟，设计是由问题领域驱动的，而不是随机的想法。
如果某些“其他”实体也似乎是评论的组合，则您必须返回领域专家并尝试确定真正责任所在。
一对问题是“如果评论被删除，评论会怎样？”以及“如果神秘的‘其他’被删除，评论会怎样？”这可以帮助找到责任。
Responsibility belongs with review. It's an aggregate of comments. Count is a first-class feature of any aggregate.
Comments are accessible via a Review. A Review is an aggregate of comments.
"What if" questions are hard to answer without a concrete and specific example. After all, the design is driven by the problem domain, not random thoughts.
If some "other" entity also appears to be a composition of Comments, you have to go back to the domain experts and try to determine where the real responsibility lies.
One pair of question is "if the review is removed, what happens to the comments?" and "If the mysterious 'other' is removed, what happens to the comments?" This can help find the responsibilities.