Hm... In the given example without knowing the context I would in 10 out of 10 cases model BusinessOrder and CustomerOder as separated classes (without common parent). In my experience Customer and Business Orders have different domain meaning, different business flows, different payment flows.

Yes, I tend to know the implementation - keeping things less abstract, more concrete. And in my experience this approach makes code simpler even in cost of "duplication".

But if You have a valid case for an abstract domain concept, than abstract factory is a necessity ✓