Treat them similar to how you would a page type.
My guess is you're overthinking this too much and trying to over-engineer it
That's what the MVC training shows when it has you create Repository, Service, and DTO classes along with using the IoC pattern for providing custom Page Type content to Controllers through dependency injection. If I were to do the same thing for modules it would require the same "over-engineering", hence my question, "Is it worth it?".
Kentico is suggesting in their training material the following:
One of the main goals of the Business project is to hide as much of Kentico API calls from the MedioClinic project as possible.
It would seem that the answer for now is, no. Perhaps Modules should be an exception to this, where we should not bother with any additional layers of abstraction. Additionally, given how modules can have relationships (bindings) with other objects, it would be excessive to have to remodel that in the Business project. It also looks like Kentico doesn't have very useful generic providers for dealing with Modules like that have for Documents. I've found some DevNet questions that discuss this topic, but there is only very basic documentation it.