Thread
#android-architecture
    l

    Lilly

    1 year ago
    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?
    Javier

    Javier

    1 year ago
    data to domain and domain to data mappers belong to data layer
    l

    Lilly

    1 year ago
    Thats what I said. I'm asking about mapping from domain to app
    I had a typo. Maybe now it makes more sense to you @Javier
    Javier

    Javier

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

    Lilly

    1 year ago
    But domain layer can not access classes from app layer, this violates the Dependency Rule
    m

    Marko Novakovic

    1 year ago
    @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
    @Lilly one other thing on
    clean architecture
    as we use it on Android. do not have 3 layers:
    domain
    ,
    data
    , and
    presentation
    . that's fine for small apps but for slightly bigger ones that's not good. that practice goes against core principles that
    clean architecture
    stands for -> change you should have
    domain
    ,
    data
    , and
    presentation
    layer PER feature but not for the whole app. main problem with having these three layers across whole app is that when you want to add something, api call for example, you have to change all three layers -> add method call inside
    domain
    , implement it inside
    data
    and call it from
    presentation
    so every change calls for changes in every module which is not good
    l

    Lilly

    1 year ago
    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?
    m

    Marko Novakovic

    1 year ago
    @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
    l

    Lilly

    1 year ago
    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
    m

    Marko Novakovic

    1 year ago
    @Lilly pass
    domain
    model into
    app
    module and map it inside
    app
    .
    domain
    should not work with
    domain
    nor
    data
    models
    l

    Lilly

    1 year ago
    Alright, that was also my temporary solution. Thanks
    m

    Marko Novakovic

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

    Lilly

    1 year ago
    Yeah I just needed some confirmation about it. There aren't many up-to-date
    clean architecture
    samples out there
    Javier

    Javier

    1 year ago
    Domain layer is not accessing to app layer, mappers are on app layer
    app -> domain -> data is wrong
    domain hasn't to implement data
    data is the external layer in clean
    so almost nobody has to implement it
    m

    Marko Novakovic

    1 year ago
    @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
    l

    Lilly

    1 year ago
    @Javier
    app -> domain -> data is wrong
    app -> domain -> data is the data flow not the flow of dependency rule 😃
    @Marko Novakovic with original implementation you mean the concept by uncle bob? What do you mean with stable 2.0? 🤔
    m

    Marko Novakovic

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

    ursus

    1 year ago
    I dont know much about clean but consument should adapt/map
    j

    Joost Klitsie

    1 year ago
    @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.
    Clean code is something you do for your future self
    (or colleagues 😄 )
    m

    Marko Novakovic

    1 year ago
    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
    l

    Lilly

    1 year ago
    @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.