I am not sure what do you mean by "failed MVC for .NET". I spend a few years writing web apps in MVC. It is basically a way to expose some code as HTTP endpoint

I am not sure what do you mean by "failed MVC for .NET". I spend a few years writing web apps in MVC. It is basically a way to expose some code as HTTP endpoint. Nothing less and nothing more, there is auth stuff that mostly works out of the box, if you are doing integration with Active Directory it gets extra easy to setup the auth. The last time I had a chance to work with it they added async (although it was not foolproof, it mostly worked). API layer is just a thin layer that either calls some other code (layered architecture) or is delegated to the "outskirts" of application (ports and adapters architecture). There should be no references to framework code in the application "domain" (DDD) code. By using alternative (beatter) IoC container you can get rid of any dependency on microsoft libraries. Now I write in Java/Spring but the attitude that I use is the same. No framework code mixed with domain code. Sometimes it means I need to write stupid adapters that e.g. use spring @Scheduled but it allows me to switch to another framework without much work. For some people this will be over engineering, for others this would be good architecture.