Question

I’ve built an open source application, and I’d be curious to know how others are handling customer-specific requests. It’s important to me to keep the app simple; I’m not trying to make it all things for all people. Apps can get bloated, complex, and just about unusable that way. However, there are some customer-specific options that would be nice (it just wouldn’t apply to all customers). For example…

Say we have a domain entity called Server. In the UI, we let a customer pick from a list of servers. For one company, it’s helpful to filter the servers by location (US, Germany, France, etc…). It would be easy enough to add a server property like this:

public class Server
{
    public Location Location { get; set; }
    // other properties here
}

My concern is that Server could become bloated with properties over time. And even if I only add location, not all customers would care about that property.

One option is to allow for user-defined fields:

public class Server
{
    public string UserField1 { get; set; }
    public string UserField2 { get; set; }
    public string UserField3 { get; set; }
    // etc...
    // other properties here
}

Is that the best way to handle this? I don’t like the fact that type safety is gone by making everything a string. Are there other/better ways that people are handling issues like this? Is there even a design pattern for something like this?

Answer 1

In my opinion, a good design pattern for something like this is to use schemas at the database level and then basic inheritance at the class level.

CREATE TABLE dbo.A (
    ColumnA INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
    ColumnB VARCHAR(50),
    ColumnC INT,
    etc.
)

And now we have a client who needs some specific functionality, so let’s create an extension to this table in a different schema:

CREATE TABLE CustomerA.A (
    ColumnA INT NOT NULL PRIMARY KEY,
    Location VARCHAR(50)
)

But now we have another client who needs to extend it differently:

CREATE TABLE CustomerB.B (
    ColumnA INT NOT NULL PRIMARY KEY,
    DataCenterID INT
)

Though the fields may not be relevant, you get the idea, and so now we need to build the customer specific domain models here:

public abstract class A
{
    public int ColumnA { get; set; }
    public string ColumnB { get; set; }
    public int ColumnC { get; set; }
}

public class CustomerA_A : A
{
    public string Location { get; set; }
}

public class CustomerB_A : A
{
    public int DataCenterID { get; set; }
}

And so now when we need to build something for Customer A, we’ll build their subclass, and for Customer B theirs, and so on.

Now, FYI, this is the beginnings of a very dynamic system. I say that because the piece that’s missing, that’s not yet dynamic, is the user-interface. There is a significant number of ways that can be accomplished, but way outside the scope of this question. That is something you’ll have to consider. I say that because the way you manage the interface will determine how you even know to build which subclass.

I hope this has helped.