Seeing this as easy, and building a custom application to handle it, will quickly become a bad idea, and an artifact of
"not build by me, I can build better" mentality.
Being able to leverage a tool that is both proven and easily available to solve this problem makes sense.
Expecting the cms to solve every problem and be the only tool used is also a big problem.
As to whether to provide the users with a means to define new pricing models and change current models, depends on how frequently it needs to get done, how much dev resources are needed to keep up with demand, and what the release process is like.
If you are in an enterprisy place. First an issue must be created to update the pricing model or create a new one.
This probably goes under change control, and it will be addressed in the next meeting of the governance committee.
If all is approved there it will be passed on to the project manager who will create a backlog item for it.
Then once the current sprint is completed, a new prioritized list of tasks are distributed and in the best scenario the issue is handed off to a developer with a high priority.
The developer will analyze what changes are needed, design the new pricing model, implement it, create and run unit tests, ensure it goes through CI. Then he will write the test cases for the new functionality and move on to the next issue in the back loc.
In 2-4 weeks when the sprint is over the worst case is that the dev branch is promoted and the test team is assigned an issue to test and regression test everything.
Once their sprint is done, it will be promoted to Staging
and more tests and sign offs and then after a month or two the new pricing model will hit the shelfs and the executive who requested it might already have forgotten why it was an issue to begin with, or the client he created it for has long gone with a different company
All of that to say sometimes it makes very good sense to create a decent way for the end users to be allowed to modify and create new pricing models.
Just like its easier to allow the end users to edit the content of web pages.
It would in my opinion be absurd to create an ecommerce system where the pricing and products require code to be updated. Much better to leverage an existing product or worse case write the logic to allow the users to make changes on their own.
> It would in my opinion be absurd to create an ecommerce system where the pricing and products require code to be updated. Much better to leverage an existing product or worse case write the logic to allow the users to make changes on their own.
This I disagree with. An e-commerce system that deals with limited number of products (like a printing shop) could easily start with hardcoded base prices, it will be months of growth and rare pricing tweaks in code before this starts becoming an issue (based on my own experience).