Domain-driven design action classes convention

I was wondering the following: if I understand correctly, an action class is meant to extract the business logic from the controllers in order to keep them thin. Another reason to use action classes is to be able to call the action from different places (such as console commands) rather than only the controllers.

However, there seems to be a challenge: not every business logic implementation can be easily converted to a separate action class. The parameter types might be different in some situations (even though they magically return the same, such as the Auth::user() facade function, which returns an instance of \Illuminate\Contracts\Auth\Authenticatable).

Next to this, some third-party packages or framework subjects already have methods / facades that can be considered as actions (and therefore would be redundant to extract it to an action class).

Is there some some criteria to when to create an action class, or a clear convention onhow to extract logic to action classes in all cases?

PS: should an action class also be created for queries to a database to fetch data from it? Or only mutations to the database (let's assume we are NOT using repositories)?