How can I maintain a few mostly identical software products but based on the same codebase? [closed]

Question

Please bear with me and let me explain. Say I work for a vehicle insurance company and we are trying to develop an online portal which our customers can purchase insurance policies. Let's just say we offer 3 insurance products Car Insurance (CI), Motorcycle Insurance (MI) and Truck Insurance (TI). And I shall say that 90% of these products are similar in terms of how we implement them but they differ significantly in the remaining 10%.

Let me use C# as an example to demonstrate (below code is a rough idea to demonstrate my problem not real code).

public class CarInsurancePolicy
{
    //common properties among all 3 insurance products
    public decimal MadeYear {get;set}
    public decimal PurcahsePrice {get;set}

    //specific to this particular product
    public bool HasCentralLocking {get;set}
    public DateTime SpecialDateToDoWithCar {get;set}
}

public class MotorcycleInsurancePolicy
{
    //common properties among all 3 insurance products
    public decimal MadeYear {get;set}
    public decimal PurcahsePrice {get;set}

    //specific to this particular product
    public int EngineStroke {get;set}
    public DateTime SpecialDateToDoWithMotorcycle {get;set}
}

public class TruckInsurancePolicy
{
    //common properties among all 3 insurance products
    public decimal MadeYear {get;set}
    public decimal PurcahsePrice {get;set}

    //specific to this particular product
    public decimal LoadCapacityInTons {get;set}
    public DateTime SpecialDateToDoWithTruck {get;set}
}

As you can see for each of the policy class they have properties that are mostly the same but quite different from each type. And now comes to the database part.

I don't know if I should do this

CREATE TABLE BaseInsurancePolicy
(
  //all common columns
)

CREATE TABLE CarInsurancePolicy
(
  //specific to this type of product
)

CREATE TABLE MotorcycleInsurancePolicy
(
  //specific to this type of product
)

CREATE TABLE TruckInsurancePolicy
(
  //specific to this type of product
)

OR should I do this

CREATE TABLE GiantInsurancePolicyTable
(
  //all columns and everything is NULLABLE
)

And now comes to the workflow part

We have a few basic common steps to rate any type of product. Say we take into account of the made year, KM travelled etc to form a basic rating and then depending on specific type of product and we have special way to calculate the premium.

public class RatingEngingForCar
{
   //can be common step
   public decimal GetPremium() {}

   //specific for car
   private void ApplyA() {}
   private void ApplyC() {}
}

public class RatingEngingForMotorcycle
{
   //can be common step
   public decimal GetPremium() {}

   //specific for motorcycle
   private void ApplyE() {}
   private void ApplyF() {}
}

public class RatingEngingForTruck
{
   //can be common step
   public decimal GetPremium() {}

   //specific for motorcycle
   private void ApplyX() {}
   private void ApplyZ() {}
}

Then we have workflows which again 90% are similar but 10% differ quite significantly. Then again it'll be the same for generating insurance policy (the actual policy doc) and then invoices.

So what I don't know if whether I should come up with some kind of a generic but yet flexible way to form a base classes and start inheriting and modifying to specific behaviour for each product. OR should I just copy past from the 1st product and modify for the 2,3,4,5 products?

In terms of UI, I am trying to componentize our javascript so that in general as long as the html structure is the same and the id/name/class then the functionality will be provided *automatically by including and initiating the JS. but the trouble is I will need to duplicate HTML everywhere for every products.

I don't know if I've explained my problem clear enough from a very high level. If not I will update / clarify based on comments. Thank you very much.

Answer 1

On the code side, this is exactly the problem that object orientation is there to solve. Put the common functionality in a base class and derive more specialised classes from that.

You can do a similar thing in the database. For example, have a policy table with a column for each of the common properties plus an ID. You can then have specialist tables containing the other fields (e.g. one table for car insurance) with a column that's a foreign key reference into your base table.

You could easily add a view to the database that presents these all as if they were one giant table, so you haven't lost anything by structuring it nicely.