I’ve become disillusioned with such approaches because coders tend to loose themselves in the aesthetics of ideas and architectures. And that can lead to high verbosity for something that could be much simpler, which then makes code harder to read and browse. Basically I doubt that complex software problem can actually be planned and designed without programming them first. That could well be just my own limits.

So today I prefer a bit of a “return to monke” C-style procedural approach and don’t even like OOP anymore.

I do wonder if there is a more formal framework for natural language (AI prompt) programming. Maybe LLMs could be used as an actual research tool to explore a high number of different architectures of well defined programs, and then compare them. Like have the same app programmed in hundreds of different languages, designs and idioms, and then compare them to get the answer to your question.

I used to like clean architecture. I implemented it in some large monolith applications but later on changed it. What stayed is the seperation of things by giving a dependency to a module/struct/class/object (via a constructor). The object does not need to know what has been passed to it, only that it can for example store something. The storing of something can be saving it to an SQL database, to a file, print it to console, etc. So basically inversion of control. And the basic breakup between the domain logic/business logic and the things that does the heavy lifting like a database handler, API handlers, etc.

I say, its worth investing in and learning. Not necessary to force you to do this, but to see it from this view and if its any good. Sometimes drastically different views can change how you program, without completely getting lost into it. In example, a Python or JavaScript programmer who tries out Haskell and learns how it works, does not mean will completely convert to Haskell. But it might give the person good habits reason about future Python and JavaScript code, and prepare and handle it differently.

Not the exact book, but the same author.

I’ve read two of his books (clean code and clean coder), and there are things I agree with, absolutely. There are also things I vehemently disagree with.

The main value I gained from them was by reflecting on the scenarios and his ideas on approaching them. Afterwards I made up my own mind on the subject.

They contained a good deal of subjects that I, as a very junior dev at the time, hadn’t even begun to consider, and by being aware of them, I could more easily approach them when encountered in the wild.

There’s also a historical aspect of knowing what has inspired, affected, or motivated, other ideas and approaches.

Take it for what it is, one person’s opinions. Some you’ll probably agree with, some you won’t. Just because someone is out was regarded highly in a field does not make their word gospel. It makes it worth thinking about and forming your own opinion though.

The less you read of Uncle Bobs writings the better but Clean Architecture isn’t really his idea(the original was called Ports and Adapters) its just a name that he coined and it unfortunately stuck.

I think Clean Architecture is quite useful for the kinds of long-lived application development projects that you will usually encounter in larger companies. Its main appeal in my opinion is that it prevents your domain logic from becoming entangled with implementation details of the environment in which the software will run. This makes changing out dependencies easier in case you need to switch out some 3rd party services.

Another benefit of using such a well-known architecture in general is that you will have an easier time on-boarding new developers. In a clean architecture project it should be no question where to find, for example, the database context because it will obviously live in the infrastructure layer.

A drawback of this approach is that it can make an application more complex than it needed to be, especially if you are writing a smallish CRUD application that has little to no domain logic.

To me the clean architecture is a good default to start with for monolithic business applications, where requirements might change drastically in the future, but as with anything else it doesn’t fit every use case. So, don’t try to write the next high performance game engine with it.

IME it’s an interesting read and some of the problems raised are valid, but the solutions are often unrealistic and overengineered. Same with design patterns, learn them to be aware of the problems, possible solutions, and their trade offs; but don’t feel the need to warp the entire project around it.

As with everything, don’t take it as a gospel. It’s a tool that can be somewhat beneficial in the right circumstances, and it can also be abused and lead to horrible results if used dogmatically.

Uncle Bob is seriously not a master or guru but instead more of a well-known blogger-turned-author.

(And using “Clean” in the naming of a guideline is an offence that should be punished with… cavities in his teeth.)

Bob Martin is a complete hack. He should not be regarded as an authoritative source and indeed, any claim he makes should be treated as highly suspect. He’s not worth reading.

Clean Architecture insofar as separating your application into architectural layers is broadly speaking a good thing.

“Clean” Code, Horrible Performance offers a good argument against it purely from a performance stand point. Well worth a watch. But it also does not even make code easier to maintain. It just smears logic all over the place and makes it harder to understand what is going on. Trying to follow clean code principals just makes your code worse. And if you try to point that out to anyone they just say you are doing it wrong with no proper advice on how to actually improve things.