I'd say start with layers and over time evolve the repo. For example, http, service, and repository layers. http has your request handlers and you parse those

I'd say start with layers and over time evolve the repo. For example, http, service, and repository layers. http has your request handlers and you parse those input DTOs or whatever here and call service. service has your business logic, and it calls out to repository (data layer) and once its done it returns the resulting DTO to http which just sends the response. Over time you'll probably have issues where certain layers are overlapping in functionality. at this point you might want to try out features but this is going to blow out how much code you have. I'd recommend focusing on solving the customer's problems without going insane. If you don't care about your employer or you have a clueless manager (90% of managers out there) and just want a promotion, refactor a repo that's already working (even if not optimally tidy) to be 5x more complex and then get a new job.