Android - Clean Architecture - best way to structure packages?

Question

Can you all take a look at my package structure to understand how i implemented clean architecture in android:

if we take a look at the clean architecture diagram it looks like frameworks is apart of the UI layer:

so the UI layer is apart of frameworks and drivers. so one of my questions then is it be more appropriate to have a folder called framework and then put my UI package folder and framework package inside of that ?

The app i have created is an e-commerce app and it has many payment gateways it connects to such as paypal, stripe, wePay, etc. so i have a gateway package which by the diagram above should be in the frameworks layer, correct ? because i see it has the word "gateway" in the diagram in the frameworks layer.

so to summarize here is my questions:

1. would it be better to have a new Frameworks package and put the existing UI,frameworks,logging, & gateway packages into it?

   2. then i guess likewise would it be cleaner to have a new package called interface adapters which would have my presenteration existing package in it?

   3. and create a new Enterprise Business Rules package and move the data, and domain folders into it ?

   4. the dagger package is my dependency injection code, would that be better in the frameworks package ?

So when i open the android application in the IDe, the package structure could potentially look like this:

+Frameworks
+Interface Adapters
+Application Business Rules
+Enterprise Business Rules

is that more meaningful?

Answer 1

Uncle Bob would probably prefer seeing the "business intend" of ur app in the top level folder structure. This is what I means with "screaming architecture".

so as I have described in my blog post here https://plainionist.github.io/Implementing-Clean-Architecture-Scream/ ur top level structure should contain things like

• payment
• card
• product catalog
• product search

these aspects which e.g. ur customer would also see using ur app.

on the next level I would at least separate the usecases and entities from the rest. depending of the size of ur app could could have one project per circle within each of the top level folders.

with this approach u would have a screaming architecture clearly separating different business and technical concerns.

on the other hand that would create quite some projects. u would have to balance both aspects for ur project.

(Any feedback to my blog post is welcome as well so that I can improve it further)