Does the architecture of your application tell you the intent of the application, or does it just tell you what frameworks you’ve used. A good architecture screams about the intent of the application and hides the frameworks. In this talk, Uncle Bob talks about the lost years of architecture, about how the web is just a detail, and about the best kind of architecture to use for your applications.
1st fallacy:
video: test the interactor - "yes you can test the interactor"
real-world: API guys had high test coverage / I made a simple HTTP request it all went to hell
2nd fallacy:
video: abstract everything
real-world: abstractions are leaky, even HTTP is a leaky one - things will go wrong one way or another if one abstracts too much (same thing as forcefully applying design pattern because they’re cool)
3rd fallacy:
video: easy to drop/replace the UI or whatever is most likely to change
real-world: adding lots of cruft for achieving that separation whilst also being able to deliver in a timely matter will seriously bite you in the long-run.
etc.
Don’t get me wrong - he’s making some good points the problem is that a unified framework for solving problems does not exist one has to adapt to the problem at hand.
EDIT: @iamntz how do I unlike something?
also pardon my English but I had to argue in the video’s native language 
Nu o faci 
Există o perioadă de câteva minute (spre o oră, dacă îmi aduc aminte bine) în care poți să „unlike” ceva.
Cât despre ce se zice în video vs viața reală, cred că n-ar trebui luat totul ca atare, ca literă de lege ci mai degrabă ca un workflow spre care să aspiri.
Adică ok, poate nu poți implementa totul așa cum zice Uncle Bob, dar poate că ar trebui să iei în considerare că se poate și altfel decât faci tu.
Cam asta am zis si eu Imi aduce vag aminte de DCI (Data Context Interaction) suna foarte bine in teorie si da poate ajuta sa vezi problema dintr-o alta perspectiva insa in practica it gets messy.
Noua la Syneto a functionat aceasta arhitectura de minune. Si sincer, orice aplicatie moderna si mai complexa se bazeaza pe ceva similar. Daca respecti 80% ceea ce zice Unchiu in filmulet, o sa ai o viata mult mai usoara, proiectul va fi mai usor de modificat si problemele vor fi muuuult mai izolate.
In orice caz, ceea ce este in video era o noutate prin 2010-2011, acum este felul implicit in care se lucreaza pentru majoritatea proiectelor, in cam toate limbajele orientate pe obiecte.
Eu imi bazez aceasta opinie pe experienta a mai multor proiecte la care am lucrat personal precum si pe ce stiu ca fac altii. Va scriu acest mesaj din Statele Unite, cu doar cateva zile dupa terminarea celei mai mari confrinte agile (Agile2015) din lume. Am fost speaker aici si am discutat cu foarte multi alti speakeri, si ce zice Robert C. Martin in acel video este ceva foarte natural si evident aici.
Nu doresc ca acest mesaj sa fie ofensiv, sau gresit inteles. Zic doar ce stiu eu ca se face si cum se face in lumea Agile acum. Desigur, lumea in care activez eu poate fi radical diferit de lumea altor programatori.
Cu siguranta sunt proiecte la care nu se potriveste o astfel de arhitectura, dar cred ca sunt extrem de putine. Cel putin eu cunosc foarte putine.
The microservices, SOA has/had the same ethos and look how well that worked out.
Appeal to authority much? I can use the same rhetoric to argue that functional programming is the savior of all development issues :))
cred ca e un miracol in sens pozitiv asta, macar ne putem concentra pe rezolvarea problemelor
altfel am dezbate care framework e mai bun pentru cazul X, si ne-am pieede pe drum la maruntisuri