[trhoad]

> And to be enforced you need to actually be hands on in the code base.

I think this might be a difference in opinion on whether we're referring to the architecture of a codebase or architecture of a system. They're different things.

> The right answer to systems design in 95%+ of cases is a single application modularized using language tools talking to a single DB.

There are still a ton of systems design considerations to take into account with a monolithic approach. Good architecture doesn't necessarily always imply a microservices architecture, I agree, but it doesn't mean all architecture concerns can be ignored - you just have a different set of things to optimise for.

[treis]

>I think this might be a difference in opinion on whether we're referring to the architecture of a codebase or architecture of a system. They're different things.

Either way you have to be hands on. I'm not sure how you can be hands on with a system without being in the code but I suppose anything is possible.

>There are still a ton of systems design considerations to take into account with a monolithic approach. Good architecture doesn't necessarily always imply a microservices architecture, I agree, but it doesn't mean all architecture concerns can be ignored - you just have a different set of things to optimise for.

Not really. You need to pick a language/framework & decide on your module boundaries. After that it's mostly building out functionality in the right module following the path your language/framework lays out.

[eternalban]

> Not really. You need to pick a language/framework & decide on your module boundaries. After that it's mostly building out functionality in the right module following the path your language/framework lays out.

You are in fact describing a specific architectural approach, which is not optimal for all situations. OP is considering a general approach to architecture and roles.