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?

Mouser

Answer 1

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.

Willful

Answer 2

One aspect Uncle Bob is emphasizing is that the clean architecture is screaming. That means that the top-level structure and names should express your 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: Implementing Clean Architecture - Make it scream.

Rudman

if you check my question i sort of did this in the UI folder. what do you think about that ? i dont see how i can name them differently otherwise except in the UI. so the UI layer would be screaming. – Mouser

I have seen that.i see at least some business words. Those should shape ur top level structure. E.g. folders or start of project names. Then layers like UI or data or presenters should follow. For more details I recommend my linked post – Rudman

what do you think of naming the top level packages like this to scream clean architecture: +Frameworks +Interface Adapters +Application Business Rules +Enterprise Business Rules then we can expand those to see the classes. – Mouser

i gave an answer to ur question here softwareengineering.stackexchange.com/questions/366930/… – Rudman