昨天跟老大一起理了一下计费的流程,也参考了小君君画的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。
杰伦的《稻香》在一次点中了我的穴道,好好的去奋斗,去努力,“不要这么容易就轻易的放弃 ”。
嗯,有杰伦的日子,不怕孤单~~