I’m not sure there’s much consense of how exactly to write that portion of you codebase.
The best way to prepare for future requirements is make it easy to throw away the current code and replace it wholesale (https://www.youtube.com/watch?v=1FPsJ-if2RU). There’s no way to know what future requirements will be, so trying to cater to them is guesswork at best.
On a general note I’d always suggest to start with less abstraction (less complex parameters) and more distinct functions than the other way round. It leads to the above, but also means you discover useful abstractions rather than imagine them to be useful. Simpler more distinct functions should help against “just let this existing function do one more thing”.
Your example would lend itself to extacting common query manipulating functions into their own module. My suggestion for learning how to do layering in code (without necessarily buying into buzzword architecture) would be buying “grokking functional programming”. It has a few great chaptures on how to build larger stuff out of smaller pieces and how those layers should depend on each other (or not).
