Some of these kinds of problems, it never feels like there is a good solution. What I would probably try if it were my row to hoe is to just start writing unit tests, definitely not system tests, with the intent of just sketching, not trying to do finished work or even tests you'll necessarily keep. That forces the thing down to atoms and “I wish I could just do *this* instead!” and that might give you insight as to what belongs where and why; in practical instead of theoretical/philosophical terms.

I don't think there is a best practice here. I think a lot of large projects full of concerns that should have been separated get so balled up that they can never get split up properly. Every step into that world requires two steps to back out. The code base at work is a testament to this. I honestly think a total rewrite would be easier than realigning 20 years of disparate but deeply interdependent code.

FWIW, I'm playing around with my own micro-web-framework right now and it's my… probably fifth run at it. What is helping me decide how far to go or not go is trying to write consuming code and make it testable. Might just be another learning exercise in the end though. :P