Modelling the domain

Question

I am working on the domain model of an application that stores information provided by sellers about the goods they sell on a platform. The application just acts as a data store for this information. The information is called as an "ProductFact", and may be diverse. Each example below represents one "ProductFact" instance.

1. the selling price of the item for general public.
2. the discount the seller can offer for some specific customers (an absolute amount, or percentage of the selling price).
3. the minimum quantity a customer has to buy to avail free shipping.

The above are some cases that are known as of now, but there might be a few more in the future, with no guarantee of sharing any property with the already existing "ProductFact"s. Different clients will be calling this application, each one looking for a specific type of "ProductFact".

We will be using a NoSQL backend, so db schema is not an issue. The problem is with the application layer. I am not sure how to model this particular object. I have been trying to model it as :

public class ProductFact {
    private ProductFactType productFactType; //enum for different types like SELLING_PRICE, DISCOUNTS, MIN_QUANT, etc.
    private ProductFactData productFactData; // for representing the actual data.
}

It would have been ideal if ProductFactData had a behavior, so I could have used it as an interface and created implementations or each use-case. But this is just data, and inheritance seems to be a hacky approach.

Another approach could be:

public class ProductFact {
    private ProductFactType productFactType;

    private SellingPriceFactData sellingPriceFactData;
    private DiscountFactData discountFactData;
    .
    .
    .
    private SomeProductFactData someProductFactData;
}

The client could check for the value of "productFactType" and then call the getter for the appropriate FactData type.But even this approach seems hacky.

What would be a good way of modelling this scenario?

Edit
It seems the problem statement could use some more clarity. Discount and Price are two of the many pieces "ProductFact"s that the application could store. There could be others in the future, including:

1. Information about express delivery eligibility of the product, say "ExpressDeliveryProductFact" - which areas is it available for, what is the minimum quantity required.
2. Information about the condition of the product - is it used, new?

There would be different clients querying this application, each looking for the type of ProductFact it are interested in. E.g., a DeliveryService client would be interested in the "ExperssDeliveryProductFact".
As can be seen, these pieces of information seemingly don't have anything in common, which is posing problems in the domain model.

Answer 1

To properly model in an object oriented way shift your mindset to object oriented design patterns.

For example, you can apply the Strategy pattern to apply the discount to the product price per case.

Define an interface for your discount strategy in your model:

public interface iDiscountStrategy
{
     decimal ApplyExtraDiscountTo(decimal originalSalePrice);
}

Add each type of discount as an implementation of the discount strategy. Here is a percentage discount and a no discount implementations (define them in your model, too):

public class TradeDiscountDiscountStrategy : IDiscountStrategy
{
    public decimal ApplyExtraDiscountTo(decimal originalSalePrice)
    {
        decimal price = originalSalePrice;
        price = price * 0.95M;
        return price;
    }
}

public class NullDiscountStrategy : IDiscountStrategy
{
    public decimal ApplyExtraDiscountTo(decimal originalSalePrice)
    {
        return originalSalePrice;
    }
}

Your Price model entity. It uses the setter flavor of DI to enable the discount strategy to be applied to the product's price:

public class Price
{
    private IDiscountStrategy discountStrategy = new NullDiscountStrategy();

    private decimal sellingPrice;

    public Price(decimal sellingPrice)
    {
        this.sellingPrice = sellingPrice;
    }

    public void SetDiscountStrategyTo(IDiscountStrategy discountStrategy)
    {
        this.discountStrategy = discountStrategy;
    }

    public decimal SellingPrice
    {
        get
        {
            return this.discountStrategy.ApplyExtraDiscountsTo(this.sellingPrice);
        }
    }
}

Please, note that Price may contain any other logic (i.e. "behavior") such as savings calculation etc.

The ProductFact becomes:

public class ProductFact
{
    public Price Price { get; set; }
    // ...
}

To apply the discount per customer type you need to create the following enumeration:

public enum CustomerType
{
    Standard = 0,
    Trade = 1
}

You also need to create a factory class whose sole responsibility will be to return the matching discount strategy for a given CustomerType:

public static class DiscountFactory
{
    public static IDiscountStrategy GetDiscountStrategyFor(CustomerType customerType)
    {
        switch (customerType)
        {
            case CustomerType.Trade:
                return new TradeDiscountStrategy();
            default:
                return new NullDiscountStrategy();
        }
    }
}

And that's it. Then, in your service layer you can write something like:

public class ProductFactService
{
    public IList<ProductFact> GetAllProducts(CustomerType customerType)
    {
        IDiscountStrategy discountStrategy = DiscountFactory.GetDiscountStrategyFor(customerType);

        IList<ProductFact> products = // get products from database

        foreach (ProductFact pf in products)
        {
            pf.Price.SetDiscountStrategyTo(discountStrategy);
        }

        retur products;
    }
}

Have the same mindset for the rest of your domain and most of your modelling issues will go away.