Robert C Martin - Clean Architecture and Design

> it's both easier and more profitable to tell people that they need to OOP better than to use more appropriate paradigms in the design of their code. I don't think this is quite on target. Sure, he needs to go where the people are in order to communicate to the most people, but that doesn't mean he doesn't speak out against fads if it's appropriate. This talk was really formative for me: [this video] If I remember correctly, he rails against just sticking the database in the middle of your system and calling that your architecture. If I'm remembering [link] correctly, he says OOP is no big deal, it's just encapsulation-polymorphism-inheritance, and then goes on to say things like C had better encapsulation than OO languages (you can keep your .c file to yourself, and just give someone the .h to program against.). And c-style bytes with stdin/stdout was designed with perfect forward-compatibility - programs like your terminal don't need to be recompiled even though they interact with your program (which was written after). And for the last 5+ years he's been pushing FP pretty hard, especially closure. I don't see him as pushing OO on people at the expense of anything else.

It is a pity that so much effort has been put on writing/designing this booklet. Software Architecture is very hard to 'compress' into a booklet this size. And the concepts explained seem all mixed up. Also, I never understood the difference between Software Architect and Solution Architect, I think they are just marketing tags to specify a bit more what you can do as an architect (install/customize a turn-key solution, networking architecture, software development guidance from scratch, etc). There is so much noise in the space of Software Architecture. And I think is something natural: building software is not architecture, nor engineering, nor mathematics... still it is all that at the same time. It also has strong social, linguistic and design components. Maybe it is just too new a discipline to define it clearly. Personally I find these resources more convincing than the booklet or the references mentioned inside it: For the technical/organizational (Dev teams) part Architecture without Architects: [link] Clean Architecture: [this video] [link] [link] For the Enterprise Architect part: [link] [link] [link]

I wouldn't use Ruby/Python for web development given their know issues. I'd use Java/C#/Go/Closure; two of these existed at the time Twitter was made. While those two are more verbose, the IDEs make most of that easy (I use Eclipse and AOP to generate almost all of that bulk). So picking something that's good at the start will save you in the end. People tend to think, "We'll architect it later" means "We don't have to think now". You need to think at every step. You don't need to know how you'll deal with everything, but there is a lot of rooming for being rational. You should think about fault tolerance when you start. It could be that you think you don't need much since everything will deploy to one box (and you're okay with loosing the whole thing). You need to be rational. You need to know why you did what you did and what the impacts would be. I'm going to stop picking on Twitter since they are the case study in what not to do. They learned from themselves and taught us all much in the process. Many startups don't think all this through (even if they only need to think 2 moves ahead). They over-hire. They under design. They make lots of poor choices because they think they have the runway and want to be cool with the latest frameworks. All of these actions I'd place squarely in the folly camp since Uncle Bob and other resources have been free since at least 2014 ( [this video] ).