Wenn man sich dem Thema Software Architektur nähern will, dann schießt man meiner Meinung nach mit Begriffen wie MVC, 3-Schichten-Architektur, Micro-Services über das Ziel hinaus. Das sind vorgedachte Architektur Patterns, die im schlimmsten Fall einem Missbrauch nicht standhalten.
Das würde ich nicht so sehen: Die Standardpattern erleichtern dem Architekten doch die Arbeit. Ich vergleiche Softwareentwicklung immer mit dem Haus/Städtebau. Für eine Hundehütte und einen Geräteschuppen brauche ich keinen Architekten (jedoch Grundlagen der Statik, zumindest beim Schuppen), aber bei einem Bungalow sieht das schon anders aus. Der Architekt arbeitet mit bekannten Mustern, Baumaterialien, Normen etc. und entwirft damit den Bauplan, den Bauarbeiter (=Entwickler), idealerweise angeleitet durch Vorarbeiter (Lead) umsetzen.
Ein Bauarbeiter, der ein bekanntes Pattern (Fachwerk, Klinker) im Bauplan sieht, kann hier seine Fähigkeiten anwenden und weiter verbessern. Würde jeder Architekt sein eigenes Süppchen kochen, würde auch jedes Mal Mumpitz herauskommen. Genauso verhält es sich mit der Softwarearchitektur.
Für den Städtebau (=Enterprise/Systemarchitektur) benötige ich ganz andere Pattern (Infrastruktur, Straßen- und Verkehrsplanung etc.) Aber immer sollten Standards und bekannte Techniken verwendet werden.
Nur bei neuen Anforderungen sollten auch neue Wege gegangen werden.
Ebenso, wie der Profi-Bauarbeiter die richtigen Techniken draufhaben muss, sollte der Programmierer die SOLID-Prinzipien verinnerlicht haben. Natürlich wird man DI in einem kleinen Tool nicht verwenden, ebenso wenig, wie man für eine Hundehütte oder den Gartenpavillion die neuesten Erkenntnisse der Spannbetonbauweise anwendet.