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:
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
Customerin 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.