Hi folks ! Hope everything is going well. I wanted to discuss a topic that I can't decide which opti...

# android

[Marc Planas]

Hi folks ! Hope everything is going well. I wanted to discuss a topic that I can't decide which option is better. (Architectural).

I'm building an app and i'm trying to do it the most clean and separate way so I stablished an architecture of :
View - View Model - Use Case - Repository
About models I have Domain and Data.

My question is, when using the repository pattern, should the repository, in case of creating an object,have as a parameter a Domain or Data module ?

Thanks in advance (I don't have many android folks to discuss this with) ❤️

[Alexandru Caraus]

The repository usually returns/or receives as parameter a domain object, and handles the dto model internally, its purpose is to abstract the persistence of the domain model. Internally you can save it to db, send it over to an api or encode it in binary.

[Jonathan]

Add another small layer, to map between domain and data, use this layer inside the repository and/or use case, so that they are not responsible of this task. Then you could establish that repository layer only receives domain objects and produces (using the mapper) data objects.

[Marc Planas]

Mmmmmmhhhh i get the point and it makes sense. BUT, in my case scenario (using supabase to access de DB ), in order to creat a row in a table I need to create also other entities in other tables and use that data to create the final one.
It makes a lot of sense of having a repository that got injected the others repositories to create the final entity, but i though that this could be also useful to have it on the UseCase if not, what are the use cases for ?
Also the domain model doesn't have some properties that the data model has, for example the Id of the FK (because it doesn't needs that for the view, i pass the object with the information)

[Marc Planas]

I'm a mess right now, sorry hahaha

[Jonathan]

It's ok if you don't have properties in one or the other, you could "ignore" them (null) or have a default value, if they are not nullable.

[Marc Planas]

but I need to pass them from one repository to another in order to create the new entity with his FK, thats where it lose it's sense 🫠

[Marc Planas]

maybe I could use the UseCases be the layer in between data and domain, where it transforms the Data object to Domain objects and handles all this complex operations. But it still sounds so bad, if tomorrow instead of supabase i have an Http request i will have to change the whole use case... instead of the repository, sounds like a double data layer and i'm not sure if its correct

[Jonathan]

hmm, that's why I was suggesting another layer that maps from whatever the use case handles to the domain layer, so that you keep your business logic, and if necessary, you swap your repository and update or swap the mapper as well

[Chrimaeon]

Your question is not related to kotlin, so off-topic to this workspace