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.

No.

Pass in the actual module name… def process_order(module), do: module.process() and you are ready to go.

I agree. The mechanics are inevitably somewhat different, but I think the idea is in its spirit similar: we’re consolidating a conditional and extracting it into a dedicated place. I think this is a useful pattern, even in an FP language.