DON'T Make This Clean Architecture Packaging Mistake

In this video I'll show you why you should not do this clean architecture packaging mistake!

💻 Let me be your mentor and become an industry-ready Android developer in 10 weeks:

⭐ Courses with real-life practices
⭐ Save countless hours of time
⭐ 100% money back guarantee for 30 days
⭐ Become a professional Android developer now:

Get my FREE PDF about 20 things you should never do in Jetpack Compose:

Join my Discord server:

[germenwong]

The clean architecture videos you created are still as good as ever. If you could categorize them into playlists, that would be even better! Can you also create a video about Composite and AdMob? I believe it will be very practical!

[manuelitoplus]

A video of clean architecture in a modular application would be great

[McMouse]

utils package also creates problems when you have multi module structure. For instance you have a common or core module that incorporates utils package. This utils are using by features modules. Any modification or additional to the utils package will triggered a rebuild of all modules. Thus negating the advantages of a multi module structure.

I like the idea of "specialising" utilities by layers. I've myself created a 'transverse' layer of modules that regroups that kind of stuff (even with a more diverse 'utils' module in it) that are injected from several layers, BUT I tend to treat domain layer differently, in the sense that I do not want to have any logic in it, only classes definition and interfaces. Therefore, there's no tests in it, and a util package (or module) does not seem useful to me. I've recently removed a utility package from the domain layer to my transverse one just for that purpose.
Nice thought and video, I will reflect on this a bit. Thanks!

[Alchemist]

what if a class or function is being used in more than one layer what should we do then?

[yossimaskin]

What if you have a shared logic which you want to use in more than one layer or in a few features data layer for example? If you go this way you'll have code duplications

[Alchemist]

please consider making a video about Cancellation Exception in coroutines according to this medium article: The Silent Killer That’s Crashing Your Coroutines

[pauloCosteira]

I would change the names, to make it easier to understand, something like FormatDataUtil, ErrorDataUtil, NameDomainUtil ....

[kaushiksaha]

The problem is when those files used by multiple section of apps. Like if there is files that supplies the text for different data errors. It should obviously go to 'presentation'. But as it is used by all of Presentation of different section, how to place it?

[RahulKumar-unur]

Awesome explanation as always, Philipp. One question for clarity, please. If we keep this layered features packages, where should we put the classes or packages that will be needing in all features or more than one features such as networking library and/or db setup, the ui package itself and so on? Should we create a "core" package and then create related packages in that (presentation, domain, data)?

[Varun_Sethi]

Hello Sir I wanted to know what are the prerequisites for the live mentoring class and also for the bundle course at your website. How much knowledge should one have before getting this course and how do we know that we have passed the beginner stage. I have done the basic jetpack compose from your playlist and built the pokedex app is this much enough for getting the bundle course and of not then what should I do more.

[ahmedhappa]

Are you not using a Loading Type in your Resource or DataResult Sealed class any more ?

[sergeykharuk]

According to tips described in this video where Network things should be created? For ex. Retrofit singleton instance. Should we create a separate Network module (if talking about a multimodule project) and inside it write and provide Retrofit instance?

[kentsolgule]

I find it confusing how you name packages as domain, data and presentation (or ui). It seems that in your architecture videos the domain package is used for everything that isn't dependent of android, external data or presentation. I have learned that a domain model is supposed to be a model of real world concepts that you get from the domain experts, free from implementation details. Concurrency is a typical implementation detail, for example, so classes using Kotlin coroutines probably isn't part of the domain model. If the implementation is in android lib or in kotlin lib isn't what determine if it belong in domain or application model. The data package is also strangly named since data classes belong in domain if they are concepts used by the domain experts. Of course if data classes use some specific database lib then it's probably a good implementation design to duplicate those classes both in a database layer and domain model as you do, but maybe call the package something else than data in that case?

[QuantuMGriD]

Hey philipp, Can you make a video on how to use data classes properly with jetpack compose. If we were to have a lot of properties for a composable in a single data class, changing a single value later on seems to make recompositions everywhere. So what is the the best way to do this would be a useful video! Thanks!

[AmirRaza]

But util is meant to be for global access, and should be declare under main package, isn't it right?

[phoenixshell]

To be honest, IMO Util packages are a bit of an anti pattern, in good OOP programs it's better to implement them as Objects, so your response code utils should be in an object HttpResponse and those handler functions as methods. Clean architecture has some good points, but in my mind theres a lot of questionable OO code floating around and people are focusing on the wrong things. I have seen clean code projects that have really bad OO code

[sabbibmadness]

i hate these util packages regardless of where it sits, its more than breaking clean architecture, its easy to break abstraction or Solid or worse engineering principles. it should be a layer/class specific logic sitting in the class. if more than one class need it, make an instantiatable class, inject it and structure it like a usecase or interactor. making an object class or an entire file of top level function doesnt make sense

if less than 3(or relative) classes need this logic, just duplicate the logic. you never know when the requirements change only 1 place in the app and now will you create a new function implementing this logic?

[andrermn]

except package structure != architecture