One challenge is that you are going to have more pricing models in the future, and there is no guarantee that they will conform to whatever schema or algorithm that you create today.

To ensure that tomorrow's pricing scheme fits into the schema you design today, you might need to limit the creativity of your marketing department. This is a 'bad idea', because you 'need to eat'.

Maybe what you need is a nice way to keep your code maintainable in the face of potentially wildly different requirements. Perhaps you should write new modules for the different pricing schemes, using inheritance or calling common subroutines where it makes sense.

As my friend Steve says, "Make different things different and what is the same the same." If your job is to take other people's money, the answer should be 'yes' whether the implied coding requirements violate design goals or not.

Some of the research on this topic refers to the buzz-phrase "business rules". I think the idea of encapsulating business rules into a fixed relational schema and associated algorithms is known to be problematic.

It should work perfectly the first time! - toma