关于模块化薪资系统设计方案的讨论

最近因为公司在薪资制度方面的改革，导致现行薪资系统也遇到很大的变动。故思考了一下关于薪资系统模块化的问题。
如果需要将一个系统模块化，我认为其功能必须具有通用性，就是说这个功能必须适应现行的普遍需求。那么，具体到薪资也就是要求这个模块化后的系统必须能够满足现在正规企业，或者说再强大点儿，能够满足现行的基本所有企业的薪酬计算要求。
那么这里面就涉及到几个问题：
第一，薪酬组成规则。薪酬组成决定薪资的计算规则。如何设计薪酬组成，才能使薪酬计算达到通用。
第二，计算公式的实现方法。这是薪酬计算的核心部分。如果实现计算，才能保证计算方法的变更与系统代码相互独立，以实现系统的强大扩展及兼容性。
第三，计算规则的存储。

对于第一个问题，我觉得应当统一薪酬组成，所有薪酬组成部分都视为最后薪资的一个组件，即SalaryComponent。这样，系统只需要去识别现在系统中实现的SalaryComponent，利用SalaryComponent自己的计算公式得出各自的结果，最后再进行一个累加和（当然也可以是其他更复杂的处理，只不过我觉得既然已经封装了，那么最后在封装的时候就考虑好这些处理），便能得到我们需要的薪酬。
第二个问题，计算公式的实现。在对第一问题的处理中，提到了一个SalaryComponent自己的计算公式，我们的第二个问题实际上主要针对的便是这个问题。如何通过计算公式的通用性来达到我们SalaryComponent的通用。简单的举一个例子来说，比如有一个叫“福利工资”的SalaryComponent他以前的计算公式不适用了，现在需要另用一套计算公式，但公司又不想重新开发一系统，只要业务人员改变一些设置原来的系统又能继续跑了。另外，变化比较大的情况下，公司上市了，员工的整套薪酬制度都要重新规划，但又不想换系统，因为一套人力系统从需求调研到最终的上使用一般都需要9个月以上的时间。这段期间公司如果还用以前的系统的或者直接不用系统的话肯定会弄得一团糟。
所以，我觉得在第二个问题的解决上，可以实现计算方法[b]DIY[/b]化，即让管理员自己设置计算公式。整个“DIY”界面就像一个强大的计算器（这个肯定比一般的计算器要强大，因为它还得实现各种复杂的函数功能，比如分段函数，递归函数，循环函数等等）。那么，这种计算就必须要一个强大的函数计算库来支持，就像Java.util.Math一样，只不过这里需要实现的比这个更具体，逻辑更接近业务。这里，我们可以有一个Arithmetic接口，统一所有的薪资计算。Arithmetic.calculate()实现所有的计算功能；一个Function虚拟基类，储存计算需要的环境，如参数。每一个具体的计算函数类需要继承Function，并实现Arithmetic接口。每一个计算类都应该在页面上找到对应的表示，并且通过管理员的赋值实现不同的实例化。
对于管理员设计的计算方法的存储成为这个薪资计算的最后一道工序。前面我们提到我们是通过SalaryComponent调用自己的计算公式来实现计算。最后对SalaryComponent再进行Operate，那么我们进行存储的时候第一级便是SalaryComponent及SalaryComponent之间的Operate，第二级是Function及Function之间的Operator。
这样系统在每次进行薪酬计算的时候首先进行运算组装。然后再进行计算。
但我觉得在最后的调用过程中还会涉及到一个性能瓶颈问题，如果，我们可以将存储的计算固化，也就是直接形成一个计算公式，在新计算形成之前不做改变。这样就可以大大的提交性能问题了，因为它减少了N次查询。当然用池化管理也可以解决这个问题。但这个可控性实在是不强。