Refactor tight coupling between routing DSL and configuration

[kanejamison]

Description

The routing DSL methods directly access Bunko.configuration which creates load-order dependencies and makes testing difficult. This tight coupling between the routing layer and configuration internals violates separation of concerns.

Current code

lib/bunko/routing/mapper_methods.rb:33:

def bunko_collection(collection_name, **options)
  # ...
  collection_config = Bunko.configuration.find_collection(collection_name.to_s)
  # ...
end

Problems this causes

1. Creates load-order dependencies (configuration must be loaded before routes)
2. Hard to test routing in isolation
3. Tight coupling makes refactoring configuration difficult
4. Routing layer shouldn't know about configuration internals
5. Can't easily mock configuration for testing
6. Makes the routing DSL less portable

Pros of refactoring

• Clearer separation of concerns
• Easier to test routing logic in isolation
• More flexible for future changes to configuration
• Reduces coupling between layers
• Better follows dependency injection principles

Cons of refactoring

• Adds indirection
• May require passing configuration as a parameter
• Could complicate the routing DSL API slightly

Recommended approach

Use dependency injection or a query object pattern. Options include:

Option A - Query Object:

# lib/bunko/routing/collection_resolver.rb
module Bunko
  module Routing
    class CollectionResolver
      def self.find_collection(name)
        Bunko.configuration.find_collection(name)
      end
    end
  end
end

# In mapper_methods.rb
collection_config = CollectionResolver.find_collection(collection_name.to_s)

Option B - Memoized Configuration:

def bunko_configuration
  @bunko_configuration ||= Bunko.configuration
end

collection_config = bunko_configuration.find_collection(collection_name.to_s)

This provides a seam for testing while maintaining the current API.

References

• lib/bunko/routing/mapper_methods.rb:33