VBA Access - 'Design Patterns' / Best Practices

Our office got an Access/SQL_Server database that has been used and developed over several years. I am tasked with rewriting the system section by section using design principles to achieve better maintain & upgrade ability.

Question: If you are forced to use MS Access VBA, is there 'Design Patterns' or Best Practices that can be followed to deal with VBA development?

View Classes: I'm thinking of building "view" classes for entities and invoking these classes from a switchboard or from any form anywhere as needed.

Model Classes: How do you handle "model" classes? - I don't think creating a private class variable for every column is a good idea especially if you are going to make use of SQL, then again complicated computations or automated tasks could benefit form this. However this would slow down processing if you say use DAO to read the records into the model class

Passing a Class Variable to SQL: What if I got a class and I want to run a method like a.showReport(ID as Long). How would I pass an ID variable to the SQL query underneath the report?

Option A.) Write the SQL for such a report in VBA - but doesn't this obfuscate the SQL? And if a developer later on make changes to the table structure then he got to search all the classes through to update the SQL written in VBA, which in my eyes is harder than updating a saved access query.

Option B.) Write a set class method that then set a public variable used in a module function which in turn is then called by the SQL query! - Needless to say this might complicate things and the SQL will have to make a call to the function for every record which could cause performance issues (if only SQL had a way to directly call an class method?)

Option C.) Just build a simple query(saved in access outside the class) to filter on say a variable in a Form with a report on top - but then I would need to write a new query and report for every new scenario and build that into the class, also another big drawback is that the query/report is now closely coupled with the form and cant be used with out it

Naming Standards(especial query names): What are good practices? - As one can imagine after a few years of ad-hoc development there are objects all over the place, especially queries. The current db got queries that is stacked on queries which is stacked again and again (in cases where there are a lot of computations such as a payment advice) and just to add to the mess if a developer missed something and had to squeeze a query in to the middle of the query stack... let me just say the way we are naming objects now, it is not working