Honestly, I don’t like the Factory pattern. I prefer to be a bit more data centric.

For example, each vendor has it’s own way to understand the orders, so you should have something like %VendorOneOrder{}, %VendorTwoOrder{}, etc… and they you apply the processing implementing a Protocol (ProcessableOrder). Then you implement all the declared functions of the protocol. For example:

defprotocol ProcessableOrder do
  def from_order(to_order, internal_order)
  def process(order)
end

And in each implementation, you do the following:

defimpl ProcessableOrder, for: VendorOneOrder do
  def from_order(vendor_one, %Order{vendor: "vendor-one"}), do: ...
  def process(order), do: ...
end

It will not solve the case problem, but at least you guarantee that the contract is kept in place if you add more Vendors. But it’s another approach to the same solution.

Relatedly, this fits in nicely if you can define a Behaviour https://elixir-lang.org/getting-started/typespecs-and-behaviours.html for the module that will do the processing.

I definitely wouldn’t advise doing this, because it introduces a non-obvious coupling between the data in the database and the code. For example, if you refactor the code and don’t pay attention, the mapping is gone. Or even worse, some unwanted mapping might be introduced.

Instead, I’d make it explicit:

def vendor("vendor-one"), do: VendorOne
def vendor("vendor-two"), do: VendorTwo

I would then convert the string to the alias (module name) immediately after the data is loaded. Similarly, I’d convert it back to string before it’s persisted. If you’re using Ecto, you can write a type for that.