[drzel]

    plans = { 
      1.month => {standard: 10, pro: 50, enterprise: 100},
      1.year => {standard: 100, pro: 500, enterprise: 1000}
    }
    
    plans.each do |interval, details|
      details.each do |name, amount|
        Billing::Plan::Factory.find_or_create_by!(name: , interval:, amount:)
      end
    end

[bradly]

I think this is the pattern I would reach for as well, separating the data from the execution. Being declarative about the plans (either with a config file, db backend, or simply a PORO) allows the plans themselves to be agnostic to how they are used and leaves you room to write a clean API for their creation without mixing in their definition.

Also ActiveSupport has Object#with_options which has a similar intent, but I rarely ever see it used in codebases.

[Footkerchief]

Exactly. Use a fancy expressive structure if you want, but don't try to abstract away the mapping between that and the general-purpose code that it relies on. "Each domain has its own rules"? How would I even know where to look for those?