I am working on an application that has many functional parts.

When a customer buys the application, he buys the standard functionality, but he can also buy some additional elements of the application for an additional price. All of the elements are part of the same application executable. A license key is used to indicate which of the elements should be accessible in the application.

Some of the elements can be easily disabled if the user didn't pay for it. These are typically the modules that you can access via the application's menu.

However, some elements give more problems:

• What if a part of the data model is related to an optional part? Do I build up these data structures in my application so the rest of my application can just assume they're always there? Or do I don't build them, and add checks in the rest of may application?
• What if some optional part is still useful to perform some internal tasks, but I don't want to expose it to the user externally?
• What if the marketing responsible wants to make a standard part now an optional part? In all of my application I assume that that part is present, but if it becomes optional, I should add checks on it everywhere in the application.

I have some ideas on how to solve some of the problems (e.g. interfaces with dual implementations: one working implementation, and one that is activated if the optional part is not activated).

Do you know of any patterns that can be used to solve this kind of problem? Or do you have any suggestions on how to handle this licensing problem?

Thanks.