计算堆存费（多规则多事实）

昨天跟老大一起理了一下计费的流程，也参考了小君君画的UI，大概的步骤就是这样的：   

     1 输入预结号，系统根据航线、业务类型、货类和合同，返回需要计算的费用。

     2 选择需要计算的费用，如堆存费

     3 系统读取合同中计算的规则，主要是确定计费要素的规则，生成规则库（ RuleBase ）。根据规则和预结号读取事实，用户可以修改需要计算的事实。

    4 用户确认事实后，系统生成一个事实库（ FactBase ）

    5 用户确认计费，系统根据规则库和事实库计算。

  这算是个简单的用例风格的流程，发现有个流程思路更顺了（估计被打，学了这么多年软件工程怎么突然说这么一句）。

   FactBase是个伟大的发明，它其中包含了一个HashMap，存储了用于此次计算的所有事实，每个事实是一组事实项组成的，正如每个规则条件表达式是由一堆规则表达式项构成的。 这些事实项可能是属于一个事实列表（同一类事实在一个列表中）。建立FactBase的作用是 将所有此次计算需要的事实一次性取出来，然后放到一个类里，这样可以避免反复的查询数据库。

    像下面这个列表显示的那样：

   

 

 

规则：

0< 整船配载量 <5000	6< 堆存天数 <13	费率 =3.5
集港工具 = 汽车

 

事实：

堆位	堆存量	堆存天数
01	100	10

   and

集港工具 = 汽车

 

    每条规则去匹配一个事实。事实项列表如下例：

 

 

StockpilingRecordItem

堆位	堆存量	堆存天数
01	100	10
01	50	8
01	50	9
01	100	13
01	100	15

 

集港工具

{ 汽车，火车 }

 

      由于客户会有以下需求，只计算某个时间段或某个堆位的堆存费，或者只计算某种集港工具的堆存费。那么在过程中的第4步 用户确认事实就非常重要了，计算机自动根据规则搜集需要计算的数据，然后客户可以再进一步的筛选。同时该步骤也可以用来验证需要的事实的完整性。如果将 FactBase持久化，即可记录此次计算的完整依据。

     因此，FactBase的出现是非常有必要的。

 

     昨天下午的晚饭前，用十几行代码实现了一个版本，然后被我删除了，因为那时我还不确定要有FactBase，只是TDD让我有某种预感。

 

    说说TDD，它总是让我有一种进化的感觉，每次重构都变得那么自然，建立对象，分配职责，都变得那么水到渠成，不知道是因为那些建模原则已经形成习惯，还是TDD的神奇力量让我自然的就完成了对象的设计。好吧，或许是DDD的思想在potential影响我。

 

     今天，将是一场大战，我要实现FactBase，这也将连带实现RuleExpressionItemFactory和RuleExpressionBuilder。

 

      杰伦的《稻香》在一次点中了我的穴道，好好的去奋斗，去努力，“不要这么容易就轻易的放弃 ”。

 

      嗯，有杰伦的日子，不怕孤单~~