-
Notifications
You must be signed in to change notification settings - Fork 464
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Seperate Go structs for the repository pattern #37
Comments
Hey @emilgelman! I'm really happy you've found the book useful.
The domain model.
Actually, that's how it should be. Remember that your repository is not a proxy for database table's CRUD methods. It's responsible for storing and retrieving domain objects, so it needs to have some idea of your domain. Clean architecture assumes that implementation details can know about the inner layers but not the other way around. If you'd follow the second option, the database model would leak into the service layer, and you don't want that. I'm a bit confused whether you use a separate "service model" and "domain model" or it's the same one?
I'm concerned your domain objects might not be properly encapsulated if you use mapstructure to fill them. Maybe that's why using them in the storage layer doesn't seem right to you? Usually, you'd use only constructors from domain to create them, and their state should change only by the object's methods. In my recent article, I mentioned a few tips on separating the structs, perhaps it will clear some things out. If not, let me know. 🙂 |
Hi Miłosz, Thank you for the response. After reading the article, it all makes sense, thanks again! |
Hello,
Let me start by saying that I really enjoy reading your book, I find it extremely useful and very well written.
We are trying to follow the clean architecture principles in our team, and we have a question about the correct way to separate between models.
Assuming we have the following layers:
We have some confusion around the best practices around which models to use where.
For example, what we currently do:
Here comes the problem:
Should the repository layer accept and return a domain model, or a database model?
If it accepts and returns a domain model, each implementation is responsible for decoding it to the whatever it wants, which feels more robust. However, it means that the repository layer is now aware of the domain layer, which doesn't feel right.
So basically my question is: which of the following options is considered more correct:
Appreciate your response!
The text was updated successfully, but these errors were encountered: