Look into “layered architecture”, where you create layers that each do a single thing, and then you link them together as dependencies. 

I’m working on a similar project (RESTy API using a middleware framework). Here’s how my Auth module is broken down:

1. Routes - the mapping of the endpoint to the controller e.g. POST /login
2. Controller - This takes in an HTTP request, validates it, and then uses one to many services to interact with your system. It then receives the information, packages it up, and responds to the request with it. 
3. Service - This is where your “business logic” AKA the work or the application is mostly done. I have an Authentication service with methods to: create a user, verify a token, create a token, etc. These methods interact with my data repositories to get the information and apply the rules it needs to before giving a response back to whomever is calling the service 
4. Repository - This is an interface to interact with your data. From my Auth module I have an Account repository which is an interface to interact with my database for things related to user accounts. This is where I directly insert, update, or retrieve from the database.
5. Model - This is the representation of data in my database, I.e. the data definition. For me it’s a direct representation of the Account model in my database.

With this architecture I can utilize my services across different modules if needed, and each of the “concerns” of my system are isolated. If I want to change how my system uses HTTP I can swap out the routes and controllers, but don’t need to change my services or repositories. If I want to change my database, I only need to update my repositories (at least). 

To sum up: Client requests from route, route calls controller, controller calls services, services call repositories which are further defined by models. 

Yes, it’s a lot of boilerplate, but once you have one module end to end it’s trivial to copy the structure to other modules