Ah, that's different 😅 also to be taken into consideration!

It would be best to keep things Laravel-friendly in terms of structure, this is what we try to achieve most with Lucid. Since resource classes are generated in the Http directory they’re best suited to remain there. A RespondWithApiResourceJob is a good idea of course 👍 in that case it gets passed a combination of resource class name and the model. Otherwise, you could create decorator jobs (specialised jobs) to return a resource per domain, but that could become overhead with a lot of models/resources.

As for resources within services, they’d still reside in the Http dir of the corresponding service (e.g. app/Services/Auth/Http/Resources/UserResource.php however, these resources may only be used by the service (in principal) meaning that services will not use each other’s resources. This is beneficial when resources are different from a service to another, but will not work if you want resources to be available app-wide instead of at the service level.

Another approach would be to put resources next to their corresponding models under app/Data, e.g. app/Data/User/User.php and app/Data/User/UserResource.php this allows the entire application to use them (services, domains, etc.).

The reason why Lucid hasn’t adopted one approach is because it depends on the scenario and the personal/team preference. All approaches are equally valid.