Our system was initially created around the client's ordering logic which is received by an API. This was allowed by the previous I.T. dept.
However over time (after growth) many different clients with differing systems send their order's to our API which have to be cleaned and changed into our working version, examples are filenames without file types for images which have ',jpg' added to the filename, or statuses that are strings ie 'finished' that are converted into our new status of int 2 etc.
There are huge sections of if statements and switch statements that change things based on who the client is which has created God controllers which have all this logic whilst the models are anemic, and I need to service the code whilst refactor as I go, but there are little in the way of tests etc.
I'm not looking for a way to decide on design patterns, but want to know what design pattern(s) are best to have a core logic and surrounding client specific logic when refactoring God controllers.
Ideally I would encourage a single robust logic with customers overtime that would accept certain variations.
Whilst I commented on a service architecture it seems that we are not using the service pattern.