I haven't seen one. You will find articles that tell you that you must use unbound forms and you must use stored procedures, etc. However, since Access is a RAD (Rapid Application Development) tool, it comes with baggage and if you are willing to accept the baggage, you really ought not to give up all the advantages that bound forms give you by doing all that manual work yourself. So, in my opinion, ignore that advice if you intend to use Access as your FE. Use bound forms and saved querydefs. You might gain some speed advantage to using views in some situations but the views will need to be updateable so you can bind them to forms for updating. You can use a query to select a view and apply criteria to it just as you would to a table. In the 25+ years I've been using Access, I've only written a couple of stored procedures and those were for very complex reports with subreports or for nightly batch processing that I wanted to run on the server rather than on a departmental computer.
The essentials are that you have to understand that a big benefit of using a RDBMS is to take advantage of server side processing and limit the data pulled down by Access. To do that, you bind your forms to queries and those queries include selection criteria that severely limit the number of rows and columns returned. One row is optimal for the main form. Subforms have to bring what they have to bring although you could control that also if necessary. You also need to understand that the server does not have VBA installed and so if you include UDF's or VBA functions in your queries, they cannot be processed by the server and that makes Access have to do some extra work to separate out those parts of your query that the server won't understand. Some VBA functions have SQL equivalents and those are fine. So, depending on where in the query your non-SQL functions appear, Access may have to ask the server to bring down entire tables and then Access will perform the joins and where clauses locally. You want to avoid this at all costs so be aware of how you use functions in your queries. Access will attempt to "pass through" all queries but you can defeat that so be careful. Don't use delete queries that delete all the rows in a table. Use Truncate instead. It simply drops the table and doesn't do any logging. Access runs all queries inside a transaction. You can tell this because you get a message telling you how many rows will be affected and asking if you want to continue. If your query affects too many records, Access won't ask, it will just do the update. So, sometimes, if you have large updates that you want to run, it might be more efficient to run them as pass through queries rather than letting Access embed them in a transaction.
The real power of Access is its ability to link to tables in any data source that supports ODBC. You don't have to understand the technology, you just have to understand the limitations as I mentioned above. As long as you use linked tables and Access queries, you can swap the BE at will. An application that I write initially linked to ACE tables, can in a few minutes be converted by relinking the tables to DB2 or Oracle or SQL Server with no changes. If you have ever worked with multiple RDBMS', you know that they all use their own variant of the SQL language. There is a basic definition of SQL and each RDBMS adds additional features and might use slightly different syntax. If you build an app using VB or C or anything EXCEPT Access and you want to change your BE from SQL Server to Oracle, you have to rewrite all your queries and stored procedures and views. Not so with Access. Querydefs are the equivalent of views and your VBA code serves as stored procedures and those don't change when you swap the BE's unless you are using some special feature.
I would use SQL Server Express since if your clients have SQL Server, they would be able to use their installation of SQL Server instead of Express.
It's not clear if this is an application you are selling to the public or building for a large client. Much as I love Access, it isn't really well suited to a shrink-wrap install although there are tools that can install the Access runtime and set various Windows security values for you. But the real downside is that Access is not a compiled platform so you don't distribute an .exe. VBA is interpreted which is why you need Access (or the runtime) installed and the best you can do is "compile" to an .accde which I recommend that you then rename to .accdr. The .accde can be decompiled to produce your source code so it may be harder to retain control over your intellectual property.
I only have one app that is sold to the public but it is not "shrink-wrapped". It is a high end product for which the clients pay thousands of dollars each year for support and training. It is a niche product so there really isn't much risk in the client attempting to steal the code plus the contract he signs is enforceable so I don't worry about it. The clients can install using an ACE BE or SQL Server. I don't do the SQL Server install, I send a .bak file to the client's DBA and he does the install and sets up al the backups and security. I