I’ve had this same goal. At the moment, I have been learning about ROM by creating an adapter for RubyEventStore. The way that I’ve structured the project is to have the relation implement a specific interface/API that repositories can use interchangeably.
For example, I’ve created a SQL and Memory adapter, which each define the relations. Each adapter is setup so they can define the relation classes to use. Checkout the memory.rb and sql.rb classes for setup and memory and sql adapters for implementation. The repositories expect the relations to have certain behavior.
To accomplish wiring things up “dynamically”, you’d want to create a ROM container at runtime rather than when booting up. What you’re doing is using a new container per setup you need, when you need it. It should be the same process as when you configure ROM with
ROM.container or something similar.
I haven’t gotten to this point quite yet, so I don’t know if there’s any performance issues or if this is 100% the best way to do it. But my learnings have been that you just need to think in terms of ROM “containers” and create as many as you need so you have isolated configurations for multiple purposes at the same time.
Hope that helps.
P.S. Please report back with what you go with!