Uncle Bob's clean architecture approach - what is recommended package structure?

Question

I'd like to know if I'm using clean architecture the right way. I am trying to lay it like this diagram:

I've read that the package structure should be arranged by use case but I'm having difficulty following how that would be done.

Let's take a look at my package structure:

notice I don't know where to really put the activities in the UI folder, could you recommend ? does it matter?

In the data folder, I have my repositories I use for repository design pattern. my retrofit network calls are on the same level as the UI folder. likewise for my dependency injection framework.

My concern comes after reading this publication I am now wondering if I did the package structure correctly?

Answer 1

One aspect Uncle Bob is emphasizing is that the clean architecture is screaming. That means that the top-level structure and names should express ur business domain and not technical details and frameworks u use. On the second level we should separate the different circles.

In an e-commerce app things like cart, search and product catalog would shape the top-level structure. Use cases, controller and presenters would be on the second level.

I have blogged about this with more detailed example here https://plainionist.github.io/Implementing-Clean-Architecture-Scream/

Answer 2

I would suggest you have a look to this repository. You can have a lot of feedback from the discussions in the issues section. I'll would read specially this discussion.

Now in orther to answer your question.

• Does it matter? I would say no, it does not matter. Package structure is only a convinient way to structure your code to make it more readable and mantaiable. As long as you respect the Clean-Architecture principles it does not matter where you have your classes. Remember you can always do a refactor while you are progressing and your project is growing.
• Where to put activities? If you already separate your UI package in components, you should stick to it and have an activities folder.
• Recomendations: first I like to have one package or even a module for each layer (e.g. data, domain, presentation, infrastructure...) then within each package you can make your own decisions that you prefer. For example, I like to separate the presentation layer into features but the domain and data layer by components. The benefits of having one module for each layer is that if a new developer is going to contribute to the project you can enforce the clean architecture principles since they wont be able to reference a data class inside a domain usecase.