This approach would work like a charm for the small projects or a single module projects. In other case you'll introduce dependencies in your domain module on the data layers, which is not so good, obviously.
In the clean code arch. , you have one way dependencies. So, the data layer knows about the domain layer, but not vice versa. So, you should have the converter functions inside the data layer, not domain layer since, the domain layer doesn't know about Dto and Entity, but, the Dto and Entity know about the domain layer .
In your case, couldnt you simply define User as an interface, implement it once (lets say UserImpl) and UserDTO and UserEntity could just take a UserImpl via delegation? No extra library/annotations required and a guarantee that your implementations all follow the contract of the inferface
We do have really simple mapping classes like that, but often there's at least one conversion. So I don't see the immediate benefit of this for me/my team
No, this is a BAD ( useless ) library. It's OBVIOUS why. Imagine an entity class ( db ) without db annotation? Imagine a network model ( Dto ) without network ( gson, moshi, jackson etc ) annotations?
You didn't understood the approach correctly,,,, Your DTO/Entity class will stands where It is,,,, this library gives you mapper functionality like we do it manually..... It. has nothing to do with DTO/Entity annotation....
Amazing teaching, doesn't expect that you know everything beforehand 😀
Thank you for creating a library to avoid this repetitive task of writing mapper function. Great contribution from you. Kudos!
this is great! I wanted to implement something like this myself, because I'm tired of writing mappers in "clean code" codebases
This approach would work like a charm for the small projects or a single module projects. In other case you'll introduce dependencies in your domain module on the data layers, which is not so good, obviously.
Exactly what I was looking for!
Hey bro your videos are on point and great. Keep posting buddy. Numbers will come. Keep up the grind
Thank you for your kind words, that really motivates me 🙂
Thank you so much for this
Nice work. Does this support kotlin multiplatform.Thank you.
In the clean code arch. , you have one way dependencies. So, the data layer knows about the domain layer, but not vice versa. So, you should have the converter functions inside the data layer, not domain layer since, the domain layer doesn't know about Dto and Entity, but, the Dto and Entity know about the domain layer .
Actually, this is very interesting.
In your case, couldnt you simply define User as an interface, implement it once (lets say UserImpl) and UserDTO and UserEntity could just take a UserImpl via delegation? No extra library/annotations required and a guarantee that your implementations all follow the contract of the inferface
We do have really simple mapping classes like that, but often there's at least one conversion. So I don't see the immediate benefit of this for me/my team
No, this is a BAD ( useless ) library. It's OBVIOUS why. Imagine an entity class ( db ) without db annotation? Imagine a network model ( Dto ) without network ( gson, moshi, jackson etc ) annotations?
You didn't understood the approach correctly,,,, Your DTO/Entity class will stands where It is,,,, this library gives you mapper functionality like we do it manually..... It. has nothing to do with DTO/Entity annotation....