Side effect as a common object seems like a bad pattern

Question

Given an auction system, there are several ways to apply a discount to the transaction's final amount, e.g.

• Special discount for a given seller
• discount for a given buyer
• Discount for a specific buyer and item combo

etc...

Given how confusing and complex the business logic could be for discounts, there is a proposal to move all discount logic into one object called "discount" and create one table/class with all the possible discounts with the columns/properties: name, discount amount, discount rules, and discount type. Discount objects would map to things like buyer or item through an intermediate target mapping object.

This all feels a bit complicated and maybe we should have different discount amounts set to objects attached to the different underlying objects, e.g. in the seller object, as a collection of discount situations to a buyer, etc..

Which is the better approach, creating one discount object to rule them all or implementing in each scenario separately, letting the auction logic look for discount values/collections in each object it processes?

Answer 1

Giving discounts in an auction sounds counter intuitive and potentially illegal, but generally the approach for "modifiers to an order" would be to define the logic for each discount type in its own class.

The reason to do this is because you are often coming up with new offers or discounts and there is no inherent structure to them.

The business might decide that "buy one get two at 90% discount as long as its tuesday and you live on a mountain but you have to add an admin charge" is the new great way to boost sales.

You will need to implement this without breaking any of the other million and one discounts, offers and extra charges.

You might need to only apply one, or all, or the best discount.

You will need to remove old discounts that are no longer valid.

Your life will be easier if each discounts logic is contained in its own class and not intertwined with the others. You could have something like:

MyDiscountType : IDiscountType
{
    Discount(ExtraInformationNotInTheOrder extras) { ... }
    bool IsApplicable(Order o)
    {
        //check the order and extra info to see if the discount would apply
    }
    Invoice Apply(Order o)
    {
        //double check the discount applies
        //process the order and extra info to produce an invoice or modify the order.
    }
}

Now you can loop though all the types of discount, see which ones apply, see which one produces the cheapest invoice, have some combination rules etc etc