What exactly is "Clean Architecture"? How and where to use?

Question

I have seen several times in replies and in other pages the term Clean Architecture. What exactly is this? How was it created? Where and how should it be used? There are alternatives or contraindications to its use?

Answer 1

The term was coined by Uncle Bob and the canonical information on this is in his page.

It is a technique, which can have its effectiveness, to better explain something already existing, and of course, to sell books and courses, since it seems something new. Not that this is all wrong, but it’s good to be clear that it’s not something new. Deep down it’s just good old separation of responsibilities, which is something good if applied right. And this requires experience.

Where the graph gives a good indication:

This shows that it is not very different to make different layers and with clear definitions of what each one does.

The book states that it doesn’t have to be exactly these layers, it can have more or less of them. I’m glad it has some openness. Some say it should only have the domain and infrastructure (business and application).

The idea is that what is more inside the circles should not know the implementation details of what is most out.

It didn’t have to be circles, it could be a pile.

Therefore:

• entities should not know
• how they will be used, you should not know
• how they will be processed for contact with the external world, which should not know
• how should be the DB, UI and platform.

And I agree with that, don’t get carried away by the criticism I’ll make.

Not everything is so clean

_{Here I begin a critical analysis because in a simple way it is above, and to understand with depth it is better to study deeply, it is not possible to delve into an answer here.}

One of the problems is that frequent changes occur above (Inner Circle) and not underneath (Outer Circle).

Have you noticed that the opposite is not true? Because it is even very difficult to do, especially if it is done in both directions, and the opposite would be more advantageous for the maintenance of systems.

Do you realize that if you change one entity you have to change all the other layers? And this happens a lot, the change of architecture changes little.

I’ve been trying for years or decades to find a way to facilitate the changes that happen a lot, with some degree of success, but I haven’t had as many opportunities to test, and for that I do a lot that goes against what everyone else usually preaches, but gives a result absurdly greater than that of clean Architecture.

If done right to such a clean architecture can be good for your system, especially if you can afford the additional complexity it generates. In the ideal world everything should be just like that.

As far as I understand it preaches the use of anemic objects, which goes against other philosophies. I will not enter into the merit who is right because obviously both are for each case, the problem is to be dogmatic.

There is a lot of discourse in the methodology that is not supported in practice, even if it would be legal to support itself. The book is vague on points that can be contested.

Independence

He hits a few points:

• Independence of frameworks - usually this complicates the development and almost always does not need, and if it needs will be ineffective, even because the person can never predict the future, you do not exchange an easy framework without changing various system philosophies and without much work. In addition to not leaking abstraction will do several very bad things, becomes inefficient, and still adopt such a minimum common denominator that makes you not take advantage of all the good of the framework that you’re using. If you believe you can make everything look great I know you’re inexperienced, even if you’ve done it for 30 years.

• Testable - Something good, but many people complicate the real system just to be able to test. You can do this cleanly, but almost everything you teach about tests out there doesn’t help that much and complicates the architecture (not that everything gets complicated).

• Independent of UI - It’s no different from the first, which shows how this was poorly thought out, and it’s a good thing, to some extent, just not for any case. In practice, few do this and only having this independence may not be enough. Depending on which part does this abstraction can be bad as I already said in the first item, it is only interesting when the UI is already naturally decoupled (client-server), which today is common, but as some Uis are coupled with the last item (blue and green circle) and you have no control over it, it’s a problem (web, cof cof).

• Database independent - it’s the same as the first item and it happens very unnecessarily falling into the problems I mentioned initially. This is even true for the use of Orms (and if you follow what was said you abstract DB and ORM, terrible, but there are many people who are reference preaching it). You will not exchange the database and mainly will not change the database model without affecting a good part of the application fundamentally.

  I find it useful in case you have a "shelf" product that needs to suit everyone, but understand that it will be a product less efficient than a made in house, which is a contradiction because a product should always be better. Unless you actually make completely different solutions, which will cost a lot more, but is the most correct solution. The solutions one fit all always charge price later (no matter what that price is).

  The interface with the database is always very specific, especially when changing model, and the model itself you marry it or use DB in a very bad way, which causes people to start adopting several bad techniques to compensate for the defects caused by it.

• Independent of external agents - it’s just another variation of the first item.

If you understand that separating things is good, but making everything plug and play No, then you may have understood the purpose of separating responsibilities.

Focus on the separation of responsibilities and not on the independence of things. Separate to be easy to give real maintenance, to deal with what happens "every day" and not with what may occur once in a lifetime.

A change of architecture will always be traumatic, there is no escape. When there is a change of architecture it is common to change even language.

Believe me, I’ve always wanted to make everything beautiful as methodology preaches, decades before it exists, or even after, and I’ve spent my life trying to allow this exchange of technologies so easily, but I’ve never come close to getting a good result. And I did that by consulting a lot of very good people. You can make it easier, but the deeper you go, the more expensive it gets, to the point of practically reinventing everything and falling into the call Second System Effect.

Naive people will adopt the methodology without understanding everything that involves it and spend their whole lives defending their mistake as something certain, I’ve seen it happen literally thousands of times.

Some people will notice that the DDD is just a specialisation or at least a later form of it. Just like the article linked shows other terms used to indicate almost the same thing.

Counterpoint

The mistake is as in the past that everything was done together. You would enter a function, read the database, process something, present it to the user, validate it, process it, set it up right there, and record it at the end.

Usefulness

I think you should study this to see more details how to do it, but you should not limit yourself to this technique, you should not think it is useful on its own, and you should not think it should be used entirely. If you have critical thinking and many sources of information then you can understand how it will be useful to you. Because deep down it’s just a more detailed and specialized way of learning what I’ve already answered in What are the concepts of cohesion and coupling?.

I think that often it ends up creating undue complications and so of clean can have only the name.

It might just be because people don’t know how to do it right, but that’s the problem with these things, it’s beautiful on paper, it’s a great cake recipe, but in real life it’s hard to get it right and really clean. And the more stuff you put in the code tends to be less clean, unless you’re good at it, which then makes it so you don’t need that cake recipe.

The criticism is more about the use and not the technique of clean architecture. It’s like OOP, people do it because they said it’s good, but they do it wrong, for them it’s not about being right, you just have to say it’s fashionable.

Where to use

So you should only use where:

• the team has experience
• is doing something complicated
• has a lot of uncertainty about the architecture, which can be a problem to be solved before and eliminate uncertainty, in many scenarios
• pays a high price to have some ease in changing the course of the solution radically

This is not to say that you should not use at least in part. Learning will make you code better at specific points, adopting partially.

Learn to do right

And how do you train it if it costs so much? Someéns (I made a point of the unusual plural because there will be several cases) will pay the bill for your learning, and this account is very expensive. Maybe someone will have an advantage in the future with their learning.

There is a better chance that it will work after you do several of them, you need to actually change the architecture and then go on learning where you failed so that next time you do not make more mistakes in the way of making the architecture so abstract. You know what? I’ve never seen someone doing this correctly (I know it exists) in the form presented in the book, I’ve seen many people say they did, when I could see it, I was wrong. It’s almost always a waste of resources in the way people do.

It’s a paradox because to do right the person needs to be very good, and if he is very good the person does the right architecture for the problem. It is similar to microservice that it is very difficult to do right, if one has the ability to do this he knows how to make a very good monolith, and does not need the microservice, but the reality is almost everyone adopts the microservice because he failed to make a good monolith.

Understand that changing all components of architecture is very complicated, and preparing for it without incurring various problems does not usually work out, and you end up having the cost of making a "clean architecture" and to change various parts of the system compared to the clean form of it all.

Do not do this in small projects, which will have little maintenance, or which will last for a short time. But if you adopt the methodology make sure you commit to the product, which is the opposite of what I see, one does and then leaves.

The first thing you have to think about is whether you should apply to the specific case you’re dealing with. People learn the technique and think they should apply to everything, and rare who learn when to say no.

It would be too long for me to cite cases that people had to change yes, but it was so long that all strategy was thrown away.

Can’t talk about how, there’s a whole book about it. I liked an article with a good summary.

You can see a project like this. Try doing this in the real world. I’m not just talking about having a lot of flair, but also applying it well. I’m not being ironic about the project, I’m being ironic about the use. And it doesn’t even follow the methodology as much as it does about being independent. I want to see you change all the components. It is still very very complicated, memso having paid a high cost to do this.

I was reluctant to post this because someone will think it’s just copy and this and it will be easy to implement.

Completion

I’m not saying that it doesn’t teach good things, that it shouldn’t learn and use where it makes sense at least parts. There is a learning there, and only by doing it many times, getting better will make you find the right level.

In theory the idea is very good, so in practice some utility has, I’m just saying that the majority people put things they don’t need, don’t benefit them, generate cost, don’t generate value, and spend a lifetime finding which is good because it followed this cake recipe.

I would love to see it working as properly as the people who propose it speak. It even works, but there are a lot of bad things that are not so visible, for example no one can demonstrate how much cost increased and how much reduced.

I’ve noticed that people adopt it without even blinking and it turns out to be a way of not needing to adopt the right architecture because "I can switch to another time you want "free of charge"".

I like it better clean design or right Architecture.

Business rules change a lot. Architecture should not change and if it changes it is normal that it has cost to do so. Almost always changing the person is signing certificate of incompetence (this is not an insult, is the term for it, I am incompetent in many things, I was in others that today I am no more because after believing without thinking the experience showed me the right way). Prepare your software for important changes. This technique helps in this, but exactly the way presented.

This technique helps you better manage infrastructure change, but not domain change. Which one do you think is most important?

Separation of responsibility is a good thing, leaving everything interchangeable not always.

Try not to marry some things like framework, measure the costs and then tell me. There’s no way I’m saying you shouldn’t do this, just understand that it costs, don’t adopt thinking you don’t have.

I’m not the only one who criticizes, see comment below and search the internet. You can start here. Still useful. But apparently some people like it unconditionally.

To learn more about architecture.