Why is impossible to have a clean architecture inside a frontend project

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:

1. Independent of Frameworks
2. Testable
3. Independent of UI
4. Independent of Database
5. 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!

Comments

[Kelvin Wieth]

Edit: this is a reply. For some reason, the original comment was removed (I think the author got banned).

I think you missed the entire point of Clean Architecture. Systems with a clean architecture will never put the domain layer inside the end-user application project, in the same codebase.

It's easy to understand:

1. The end-user application is the most likely to change
2. The domain layer should be defined in the least likely to change place
3. Therefore, the domain layer should not be defined in the same place as the end-user application

If you think this is not Clean Architecture, just watch this lecture from the author itself.

That's the same of saying "it is impossible to CA web projects because it depends on HTML or SASS"

Yes. And if you watch some of Uncle Bob's lectures, you will hear exactly the same thing. A clean architecture protects the domain layer from changes in the presentation layer - and not only from changes like "this button was red and now is green", but from ones like "we were using Flutter but now the app is written in Kotlin and Swift natively" or "the frontend was a web app and now is a CLI".

CA it's not about THAT KIND of dependency

Yeah, it is. Again, listen to Uncle Bob and you will see that the web, for instance, should be just a plugin.

SDKs and (native) APIs are not dependencies

Yes, they are. The only thing you cannot consider a dependency is the language itself, because you have to choose a language to define your domain layer.

A lot of apps are closed systems, so CA apply because THEY ARE NOT just UI

Again, if you ship the domain layer with the end-user application layer, you are not doing CA. You can call it whatever you want, but not the Clean Architecture as defined by Bob Martin.