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

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?

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.