For me Clean Code is a book I’m really thankful to have read early on, it’s got some good points on naming and separation of concerns especially. Apart from that I’m afraid that there’s no “architecture” that you could learn and follow in implementation and be perfectly happy.
From my point of view all architecture and patterns exist solely for inspiration, a bunch of it gives you good guidelines and if you understand them well enough you should be able to pick and pivot to one suitable to the task at hand. As soon as you start philosophising and following “rules”, you’ve lost. Software is complex enough that you can’t framework it all out beforehand with a set of constraints (otherwise LLM codegen would be a much more useful tool).
What you have to decide is what you care about from your software, does it need to change a lot, does it need to be extremely performant? Are you going to be doing a lot of repeated “data-piping” (DB-Backend-Frontend) or some super specific complex processing.
The frameworks give you nice starting points and rough infrastructure ideas based on your answers, but times and wants and needs all change regularly so you’ll always have to change something later, and that’s why I believe legibility, separation of concerns and a sane testing strategy are the most important parts of the equation, the rest may change with evolving requirements.