The obvious examples in the core, and most tutorials I have seen, do split the Model between the List and Edit for the plural or singular processing of record(s). And that seems too obvious an answer but unfortunately I haven't seem anything else concrete to point you too.

This is not a claim to 'best practice' but in my own code I tend to be creating a Model based on a table or data type these days for as much of the business process/logic and use Traits to share a lot of the common code to do with handling the CRUD aspects to keep things manageable.

For example I have an InventoryModel for sharing all processing related to Product Inventory records whether they are internal sources or from external sources. I might still use the single model, view, controller approach to list or edit a form but any actions beyond the basic save/close and sorting/filter will find their way back to the InventoryModel or InventoryController.

My self taught approach does have a lot of code in the Controller classes that really should be in the Models as I have learnt more about better coding so if anything my Models should get more code in them as I clean up things.

I have also used in some cases mycomponent/src/library as a place to store classes that are used to create more complete or functional objects to fill in the gap between a Model and utility type Helper function.

Another approach I tend to be following nowadays is to have the majority of the processing in Admin Model and keep the Site, API or CLI Models to a application specific requirement by either extending or Use'ing the Admin Model where possible.

I have also found it easier once you need something besides the basic one MVC per table approach of Joomla is to avoid using the 'automagically' way Joomla falls back on to locate a same or similarly name MVC element. As I try to 'modularise' my components I found it less confusing to follow by specifically defining what I want to load with a USE or boootComponent statement rather they rely on Joomla to determine what I might want.

The obvious examples in the core, and most tutorials I have seen, do split the Model between the List and Edit for the plural or singular processing of record(s). And that seems too obvious an answer but unfortunately I haven't seen anything else specific to point you too.

This is not a claim to 'best practice' but in my own code I tend to be creating a Model based on a table or data type these days for as much of the business process/logic and use Traits to share a lot of the common code to do with handling the CRUD aspects to keep things manageable.

For example I have an InventoryModel for sharing all processing related to Product Inventory records whether they are internal sources or from external sources. I might still use the single model, view, controller approach to list or edit a form but any actions beyond the basic save/close and sorting/filter will find their way back to the InventoryModel or InventoryController.

I have also used mycomponent/src/library as a place to store classes that are used to create more complete or functional objects to handle classes that fall between a Model and utility type Helper class. That may be an option for reducing the code in your Models.

My self taught approach does have a lot of code in the Controller classes that really should be in the Models as I have learnt more about better coding so if anything my Models should get more code in them as I clean up things to meet the thin controller approach.

Another approach I tend to be following nowadays is to have the majority of the processing in my Admin Models and keep the Site, API or CLI Models to a application specific requirement by either extending or Use'ing the Admin Model where possible. It reduces the duplication of code in my models and problem diagnosis is easier. 

As I try to 'modularise' my components I found it easier to specifically define what I want to load with a USE or boootComponent statement rather they rely on Joomla's automagic to resolve class names.