Hi, I have a question regarding Clean Architecture and data models. It's recommended that every layer should have it's own data model and map to the consuming layer's data model. Lets say we have app, domain and data layer. Domain layer is the most inner circle. In data layer I would map to domain model but I have problems how to map from domain to app layer. Domain layer does not know about the model in the app layer so how to map it?

data to domain and domain to data mappers belong to data layer

Thats what I said. I'm asking about mapping from domain to app

Same answer but with domain to app and app to domain mappers, they have to be in the app layer

But domain layer can not access classes from app layer, this violates the Dependency Rule

@Lilly

domain

knows only about itself, it knows nothing about

data

nor

app

so you shouldn't even try to do anything with

app

models inside

domain

layer.

app

layer can map to

domain

and vice versa

app

 layer can map to 

domain

 and vice versa

vice versa? Than domain would be aware of app

you should have 

domain

, 

data

, and 

presentation

 layer PER feature but not for the whole app.

Thats what I have. Layers are implementation details. Anyway I still don't know how to map from domain to app?

@Lilly one other thing. people often times abuse clean architecture on Android and they have interfaces and classes that just delegate calls.

ViewModel

calls

UseCase

which only forwards call to

Repository

which just forwards call to

API Service

and none of these actually does anything to the data, just passing it around. everything could be avoided with

ViewModel

calling

API

directly

Thanks for your advices. I already overcome all this stuff. I just need to know the mapping between domain and app. The data flow is app -> domain -> data and back. So from data layer I can map to domain layer but from domain to app layer this does not work because of Dependency Rule

@Lilly pass

domain

model into

app

module and map it inside

app

.

domain

should not work with

domain

nor

data

models

Alright, that was also my temporary solution. Thanks

your solution is good, that's how it should be implemented. no problem, feel free to ping anytime with anything related to this topic

Yeah I just needed some confirmation about it. There aren't many up-to-date

clean architecture

samples out there

Domain layer is not accessing to app layer, mappers are on app layer

@Lilly many tutorials and samples follow original implementation that was first version of this, we can call it alpha 😄 but now it should be stable 2.0

@Javier

app -> domain -> data is wrong

app -> domain -> data is the data flow not the flow of dependency rule :)

Uncle Bobs concept is great, nothing wrong with that. problem is with initial implementations on Android.

I dont know much about clean but consument should adapt/map

@Marko Novakovic it is not abusing clean architecture by having some code just wrapping other code. Your view model should NEVER call API directly, it should be agnostic to where the data comes from. If you do shortcuts, like what you said, you will open a can of hurt whenever you want to introduce local caching or any other logic.

having wrappers around too much stuff is abuse @Joost Klitsie. clean architecture is also about not having what you don't need and wrapping in case you need it is bad. yes, you should not call API directly, you probably need some mappings to do before getting the data and some error handles but the point is important. we all know these view models that call use case that calls repository that calls remote and local data source that call the API or database and all of that is just delegating calls 😕 nothing clean there

@Marko Novakovic I didn't argue against you because I neither want to change your point of view nor do I want to keep right, but I will share my thoughts because I also went down this long road. I confirm what @Joost Klitsie says. But you are also right with anemic use cases and repositories that just delegate the calls. I like to strictly separate the boundaries of the layers and then you will forcibly end up with anemic use cases and respositories or however you want to call those abstraction layers. But the rule that justifies having anemic "wrappers" is consistency and separation of concerns and IMO this fact makes it the only possible solution.