I have it for some applications. For smaller (<50kloc) services I use node in a functional/immutable style with minimal context objects (too convenient to go full immutable). When you learn the ctx object and the utils module you know how to make almost anything. For larger I'm still looking, but my rule of thumb is to avoid most OOP paradigms and most especially inheritance at nearly all times.
Think more in terms of the code state than the conceptual/business state, because when the code state is readable and understandable and low-overhead, it leaves you all the brain space to think about the problemset. No matter what, working on establishing patterns, share them with other people working on the same codebase, and make them better over time - build only enough tests so that you can cleanly refactor whole files, while not bogging everything down in the details. If you are ever afraid of changing a file (except at top level tooling), even in production, you're doing something wrong, because the potential footprint of your changes should be as low as possible.
