It is common practice to structure your project so items are packaged by features rather than layers. For example, if you were using mvp, you would place your login view with your login presenter, as opposed to bundling all your views together and your presenters together. There is a number of reasons for why this is good practice and a great article on this can be found here.

In large or complex projects this can be taken a step further and layers or features can be broken into sub-projects or modules, the official gradle docs do a good job of describing this process. This can further help reduce coupling and increase the separation of concerns (kotlin internal classes can really help with this in multi-project builds).

For example, let’s say you have a core module which is responsible for connecting to your api, persistence and a place for your models, then on top of that some feature modules, and on top of that an app module. So you may end up with dependencies that look like the following:

These modules will often have common dependencies and variables (think android support libraries, Kotlin, RxJava etc.), in larger projects it can become difficult to managing these dependencies to avoid dependency conflicts and other potentially strange and difficult to debug issues.