I think the problem is that when people think about 'good architecture' they're thinking 'silver bullet architecture.' There is no such thing. Different project

I think the problem is that when people think about 'good architecture' they're thinking 'silver bullet architecture.' There is no such thing. Different projects will require a different architecture. One project's good architecture may not be suitable for a different project. The architecture has to be adapted to the current and future requirements of the problem domain of the project. There are some highly generic architectures like front end frameworks (e.g. VueJS, React, Angular) which are almost silver bullets but it's still a mistake to think of them in that way and they tend to be overused. But the fact that front end frameworks can handle an extremely broad set of front end requirements is a great example of how good architecture can handle requirement changes. It's unusual for someone to have to fork or swap out React due to front end requirement changes; it's usually an indication that React wasn't suitable for their use case to begin with. It would have to be a massive business pivot and you'd have to dump the entire codebase anyway if the requirement changes where that significant. When discussing architecture in a broader sense, the front end is just one aspect. There have been many attempts to produce silver bullet full-stack frameworks (e.g. Meteor, SailsJS, DeepStream) and they are/were useful for a certain subset of projects, much smaller subset than what front end frameworks have achieved. But there are many architectures that are heavily adapted to specific business domains and which are very far from silver bullets but which could be considered 'good architectures' nonetheless because they are good at handling domain-relevant requirement changes with minimal code changes necessary.