uncle bob and his “cLeAn aRcHiTeCtUrE” was a setup all along. His teachings were conceived by managers, the most useless part of our field, to cripple and disempower developers. They wanted to make our work excruciatingly slow and unnecessarily difficult, so they could maintain their job security.

It is obvious that if you were to ditch all that useless boilerplate, the work process becomes way easier, quicker and more streamlined. In that scenario, managers aren’t needed, at all.

They have played us for absolute fools. uncle bob is the biggest disgrace to ever happen to our field. Let’s leave this dark chapter in the past and move on into the world of quick, effortless development, with happy engineers, happy business and the complete lack of burnout. Also, it is time to make managers a thing of the past.

Here is what @SortOfTested has to say:

https://devrant.com/rants/2747952/...

@kiki 40+ years exp in agile
lol

There is no clean architecture.

We have to make compromises.

Same for all the other nonsense bullshit promises: there is no 100 % scaling possible etc.

Regarding managers: Throwing bad apples out, ok. But some of us try to be good, don't put the blame on them.

I must say that there are some interesting guidelines and useful guidelines in clean architecture and DDD. There are great solutions in there if you do OOP

But when one starts enforcing that crap as a golden standard you get concept hell. Especially the dependency direction rule. It simply has no room for commitment and constantly breaks the only abstract what varies rule. So in order to use a certain object in a deeper layer you need an interface to abstract it. This leads to a single thing like handling a database view to spread out in several layers with just as many concepts e.g. abstract query builder, query dialect handler, view, view saver, db connection. This also leads to making changes in several layers when that one thing changes as it is actually artificially abstracted to adhere to the rule.

OOP was invented to couple the data and implementation together. Clean architecture forces to separate that all the time.

@hjk101 if you commit to use one paradigm and one paradigm only for a real business app, you’re doomed to fail.

@kiki have to think about that one. Feels wrong to me depending on how strict you take the paradigm part. The smaller the app the more likely it's single paradigm (and single language). There are successful Java apps and that is often regarded a OOP only language.

With commitment part I was talking about is about depending technologies. For example if you choose to use kafka don't start by making it message queue agnostic. Of course you want layers so it doesn't bleed into everything but it's ok to not be able to replace it without some changes. A MQ probably has about 3 concepts/concerns so switching should be a minimal effort as long as the new tech supports the used concerns.