I hold KISS above most "Enterprise Patterns" with YAGNI as a close second. I think abstractions should be used to reduce complexity with code as opposed to making it harder to reason about. If a pattern increases complexity in understanding, then it should make sense in more cases than not.

I'm also a fan of feature-oriented project structures. I want the unit test file in or next to the code it's testing. For UI projects, similar with React it's about the component or feature not the type of thing. For APIs I will put request handlers with the feature along with models and other abstractions that go together based on what they fulfill, not the type of class they are.

I consider this practice more intuitively discoverable. You go into a directory for "Users" and you will see functionality related to users... this can be profile crud or the endpoint handlers. Security may or may not be a different feature depending on how you grow your app (Users, Roles, Permissions, etc). For that matter, I'd more often rather curate a single app that does what it needs vs. dozens of apps in a singular larger project. I've seen .Net web projects strewn across 60+ applications in two different solutions before. It took literally weeks to do what should take half a day at most.

All for one website/app to get published. WHY?!? I'm not opposed to smaller/micro services where they make sense either. But keep it all as simple as you possibly can. Try to make what you create/use/consume/produce as simple as you can too. Can you easily use/consume/interact with what you make from a system in $NewLanguage without too much headache? I don't like to have to rely on special libraries being available everywhere.