Clean architecture article

Hi everyone :wave:

I wrote an article on why I’m sticking with clean architecture. Thought I’d share it here for people to tear apart.

I feel one thing that’s probably missing is a clean architecture description, or a link to one. Feel free to share any other feedback you might have for me.

2 Likes

The point is you can achieve all your points with any layered architecture with less abstraction in most cases.

3 Likes

It’s about abstracting the access to remote server, it’s not about clean architecture (with DTO, mapper, UseCases, what do you want more…).
Interestingly new flutter guidelines highly recommend to drop the domain layer cause most of the app have little logic: Architecture recommendations | Flutter

Thanks for sharing that link - I hadn’t seen it before.

Maybe I misread, but it doesn’t recommend dropping the domain layer - it says the use of a domain layer should be conditional depending on the complexity.

I might just be overcomplicating my apps, but I’ve got a few places where usecases are needed to lift some of the logic out of the viewmodels (blocs in my case) on order to make the logic calls to the data layer reusable. If I were stronger at backend development I’d probably put more of the work there, rather than in the client. Something for me to work on there.

Drop the layer is your app is classic CRUD app, and 95% of the apps are :slight_smile:
Domain layer is useful if you have complex logic/computation. From the new guidelines, and from my perspective, you should start with no domain layer, and just add one if it’s necessary (spoiler: it’s not in 95% case :))

1 Like