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

enter image description here

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

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?

    1. 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?

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

    3. 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:

+Interface Adapters
+Application Business Rules
+Enterprise Business Rules

is that more meaningful?


1 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)

  • but if i did it this way, where would the UI code go ? payment,card,product catelog, product search ? which one ? and where would the presenter code go ? i did check out your article it was just a little hard for me to grasp. i'll keep researching.
    – j2emanue
    Commented Mar 4, 2018 at 3:34
  • u would keep even the UI as separate as possible. u probably have individual presenters for payment, card, etc. same with the views. so u could have a project per business aspect (card, product catalog, etc) for controllers and presenters and a separate one per business aspect for views. u may then need one "shell" UI project where the individual views are used and composed into the complete UI. Commented Mar 4, 2018 at 6:10
  • For further reference: In "Domain Driven Design" payment, card,product catalog, .... are called Subdomains
    – k3b
    Commented May 7, 2020 at 12:30

Not the answer you're looking for? Browse other questions tagged or ask your own question.