英文:
How to set relationship between entites in clean architecture?
问题
最近，我开始学习干净架构的实现。现在我在创建实体和它们之间的关系方面遇到了困难。根据Bob大叔的建议，应该在每个领域中拥有实体，我可以同意这一点。
但考虑到我有一个博客，想要设计这两个用例：“创建帖子”和“用户认证”。
对我来说，这两个操作位于不同的领域（例如Auth和Blog）。如何正确设计我的架构以实现这一点？
- 在“博客领域”中有User和Post实体？那么“认证领域”怎么办，它也需要User实体吗？
- 在“博客领域”中只有Post实体？那么如何建立与User的关系？
- 在“博客领域”和“认证领域”都有User，而在“博客领域”中只有Post？那么不会出现代码重复吗？
这些是我的问题。如果有人能帮助，我将非常感激。愉快的星期天。 :face_holding_back_tears:
英文:
Recently I started to learn Clean Architecture implementation. Now I'm stuck on the way to create my entities and create the between them. It's suggested in uncle Bob to have entities in each Domain. I can agree with that.
But considering I have a blog, and want to design these two use cases: "Create a Post" and "Authenticate User".
For me these two actions are in different domain (Auth and Blog, for example). How to design my architecture in the right way to do this ?
- Having User and Post entities in Blog domain? So what about Auth domain, which also needs User entity?
- Having only Post entity in Blog domain? Then how to make the relationship with User?
- Having User in Blog domain and Auth domain, then Post only in Blog ? So how isn't a code duplication ?
Here my questions. If someone can help, I'll be very grateful. Happy sunday. :face_holding_back_tears:
答案1
得分: 3
在身份验证上下文中的用户与博客上下文中的用户不同。Eric Evans 在领域驱动设计中称之为有界上下文。
Martin Fowler 在他的博客文章中对有界上下文进行了很好的概述。
Martin的示例清楚地显示，在销售上下文中的“客户”与支持上下文中的客户不具有相同的关系。
相同术语对不同的人意味着不同的事情，因此具有不同的属性和行为。
想象一下，如果两个上下文都使用相同的“客户”，那么这一个“客户”类将积累所有上下文所需的所有属性和方法。
当您实现存储库时，您将意识到这个问题。由于存储库用于检索实体，它必须检索所有的数据。如果您只有一个实体适用于所有上下文，那么存储库必须检索所有数据，即使它在特定上下文中的特定用例中并不需要，否则它可能导致意外行为。
因此，每当您面临加载比所需数据多得多的问题时，您可能会遇到有界上下文的问题。
当然，销售客户和支持客户之间存在关系，因为它们代表同一个客户。有界上下文之间的数据同步可以通过事件机制来完成。
英文:
An user in an authentication context is not the same as an user in a blog context. Eric Evans calls this bounded context in DDD.
Martin Fowler gives a good overview about bounded contexts in his blog post.
Martin's example clearly shows that a Customer in a sales context does not have the same relationships as in a support context.
The same term means different things to different people and therefore has different properties and behavior.
Think about what would happen if both contexts use the same Customer. Then this one Customer class would accumulate all properties and methods that are needed for all contexts.
You will recognize this problem when you implement the repositories. Since a repository is used to retrieve the entities it must retrieve all of it's data. If you only have one entity for all contexts the repository must either retrieve all the data even if it is not needed for a specific use case in a specific context or it does not initialize all of the data which might lead to unexpected behavior.
So whenever you face the problem of loading a lot more data then you need, you probably have problem with bounded contexts.
Of cource there is a relationship between the sales Customer and the support Customer, because they represent the same customer. Data synchonization between bounded contexts can be done using an event mechanism.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论