The internet is full of videos, courses and articles teaching you to have something like “domain” folders in your frontend project, to create “entities” and everything that would make Uncle Bob fall apart. This little post shows why it’s impossible to have a clean architecture in this kind of project.
Clean Architecture
Clean Architecture is a set of good practices to build a good architecture. It is based on the following principles:
- Independent of Frameworks
- Testable
- Independent of UI
- Independent of Database
- Independent of any external agency
This post will not gonna dive into them. You can check the original post from Uncle Bob for more info.
Frontends are dependent
Points 1 (independent of frameworks) and 3 (independent of UI) are the reasons why you simply CAN NOT build an entire clean architecture inside a frontend project.
Let’s take Flutter as an example: Flutter is a UI framework. If your architecture consists on a single Flutter project, you’re done. A Flutter project should be a tool, a plugin, that you can remove or replace with any other UI framework. You might say your entities and use cases files does not import Flutter, but your pubspec.yaml file at the root does.
The same is true for ReactJS projects, that depends on React and on the web, Windows Forms projects with C#, iOS projects with Swift, etc. Every frontend project is highly dependent on a framework and on the UI.
What Clean Architecture is about
Clean Architecture is NOT about a single project. If you listen to Bob Martin lectures, you will notice that an architecture is about the entire system: not only your frontend app, but also the database, the domain backend, and any other backend or frontend component.
In this lecture, Uncle Bob presents a good implementation of a clean architecture, that he calls Model View Presenter. With this architecture, the domain bussiness rules are not inside the frontend project. Also, this implementation adds a so called Presenter, which makes the View as dumb as it can possibly be.
BFF
Here is the same diagram, but with other words, that you may identify more clearly:
Now, do you see where is your frontend app?
The main benefit of having a BFF (Backend for Frontend), and therefore making the frontend dumb, is to make the UI easy to change. If tomorrow another super fresh UI framework comes out, your team can easily change, and still use the same rules defined on your BFF – for instance, if the login fails, the error message should be red.
Conclusion
I hope with this post you have a better comprehension on Clean Architecture. Just remember: architecture is about the entire system, not only your frontend.
In the next days, I will try to implement this idea using Flutter and Dart Shelf. See you next time!