Architecture-samples: todo-mvp-clean: Domain package location

Created on 27 Dec 2016  路  3Comments  路  Source: android/architecture-samples

I'm just confused with the hierarchy of directories of this app. Is it necessary to put the domain packages inside each "screen" directories? Isn't it better to move it to a separate folder?
These are my reasoning:

  1. Any usecase can be called by a different presenter from a different folder
  2. Reuse of the whole domain to another app will be easier
  3. The clean architecture chart separates this as well.
question

Most helpful comment

I believe it is because as stated in the Robert Martin's presentation about the clean architecture, the top level directories should represent the application functionalities instead of the frameworks or layers.
Also I see the folders in these samples in a different way, instead of thinking of it as a screen folder I think as a Action/Functionality folder.

With that said I agree with you at some level.

"1.Any usecase can be called by a differente presenter from a differente folder"

I agree that this can happen quite often in a bigger application with both use cases and business models and I don't know what's the best approach. Maybe these shared classes could be in the top level directory but it kind breaks the structure logic stated by Robert Martin. A better solution would be to create a top level for the common functionalities and have it contains both the functionalities and the common components in it. Like this:

* app
    * generic functionality
        * domain (shared between functionality 1 and two)
            * model
            * usecase
        * specific functionality 1
            * domain (specific for functionality 1)
                * model
                * use case 
            * SpecificFunctionality1Activity
            * SpecificFunctionality1Presenter
        * specific functionality 2
            * domain (specific for functionality 2)
                * model
                * use case
            * SpecificFunctionality2Activity
            * SpecificFunctionality2Presenter

"2. Reuse of the whole domain to another app will be easer"

I never saw a case where someone would reuse the entire domain so I don't think it is common enough to consider changing the directory structure because of this.

"3. The clean architecture char separates this as well."

I believe that chart is only representing the dependency rule that states: "_Source code dependencies can only point inwards. Nothing in an inner circle can know anything at all about something in an outer circle._"

I hope this helps and if someone has a better idea about how to structure the models and use cases that are reused between functionalities please help us =]

All 3 comments

I believe it is because as stated in the Robert Martin's presentation about the clean architecture, the top level directories should represent the application functionalities instead of the frameworks or layers.
Also I see the folders in these samples in a different way, instead of thinking of it as a screen folder I think as a Action/Functionality folder.

With that said I agree with you at some level.

"1.Any usecase can be called by a differente presenter from a differente folder"

I agree that this can happen quite often in a bigger application with both use cases and business models and I don't know what's the best approach. Maybe these shared classes could be in the top level directory but it kind breaks the structure logic stated by Robert Martin. A better solution would be to create a top level for the common functionalities and have it contains both the functionalities and the common components in it. Like this:

* app
    * generic functionality
        * domain (shared between functionality 1 and two)
            * model
            * usecase
        * specific functionality 1
            * domain (specific for functionality 1)
                * model
                * use case 
            * SpecificFunctionality1Activity
            * SpecificFunctionality1Presenter
        * specific functionality 2
            * domain (specific for functionality 2)
                * model
                * use case
            * SpecificFunctionality2Activity
            * SpecificFunctionality2Presenter

"2. Reuse of the whole domain to another app will be easer"

I never saw a case where someone would reuse the entire domain so I don't think it is common enough to consider changing the directory structure because of this.

"3. The clean architecture char separates this as well."

I believe that chart is only representing the dependency rule that states: "_Source code dependencies can only point inwards. Nothing in an inner circle can know anything at all about something in an outer circle._"

I hope this helps and if someone has a better idea about how to structure the models and use cases that are reused between functionalities please help us =]

Hi, even though I would be reiterating part of the jchesterisidoro`s question I still feel the need to ask it - how would the project directory structure look like if it was meant to represent the layers of Clean Architecture?

I am not experienced with it and I was not able to spot the relevant files/folders to the architecture layers just by reading about the architecture and its principles.

I am hoping to use this approach in an Anroid app with Kotlin for my diploma project(bachelor), so I would very much appreciate if anyone would be willing to clarify which files/folders belong to which Clean Architecture layer in this particular example project.

Probably better to continue on stackoverflow.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

DharitParmar picture DharitParmar  路  6Comments

ghost picture ghost  路  3Comments

aitorvs picture aitorvs  路  4Comments

BeQuietLee picture BeQuietLee  路  3Comments

nucle picture nucle  路  7Comments