一个很复杂的建模的问题,请大家帮忙!!!

10-08-29 icethor
大家好,我是jdon论坛潜水人员,大概潜了能有四五年了吧,如果不是这个难题,估计我还会继续潜下去:)

是一个很复杂的费用建模的问题,简单描述如下:

货物运输费用中包括多种费用,现在要对这些费用进行报表,即:得出一段时间内、货物运输费用的“列表”与“总和”。

费用类型包括:保险费、运输费、上门送货费、仓储费。(需求非常不稳定)

所有费用都有“应付费用”、“已付费用”、“待付费用”三项(应付费用-全部的已付费用=待付费用)。

对于每次货物运输,只会对每个费用类型产生一项“应付费用”与“待付费用”。

“已付费用”的特殊性:

“已付费用”应该分清费用支付方:“发货人”与“收货人”。

“已付费用”应该分清费用收取方:“发货站”与“收货站”。

每次付费产生一条付费记录,作为历史记录。

(应付费用与待付费用可能也有特殊性,但是我目前还没有捕获到,比如计时、提醒等等。)

费用报表统计时的查询规则:

查询时必须选择应付、已付、待付费用三项其中之一

可以按某次或某几次货物运输进行查询,或者全部查询

对于已付费用:

可以按付款时间段进行查询,或者全部查询

可以按照费用类型进行查询,或者全部查询

可以按照支付方进行查询,或者全部查询

可以按照收取方进行查询,或者全部查询

没有计费公式。所以,如果不考虑未来的扩展性的话,费用类型之间(“保险费”、“运输费”等四种类型)没有本质区别。

超高难度问题,现在已经无法画出领域模型。(大家多提意见,多多益善哈,如果板桥大哥能来就最好了:P)

1
blackman
2010-09-02 23:35
你先谈下你的想法,如何解决等等。

icethor
2010-09-11 01:06
抱歉,公司的网莫名其妙的上不了jdon了,让我郁闷了很久。。。

“已付费用”与“历史记录”之间有着一致性关系,这个关系如果不能妥善处理,那么日后就是灾难的根源,所以我觉得这个值应该是计算出来的。

同样,“待付费用”也是与“已付费用”和“应付费用”之间有着一致性的关系,通过以上两个已知量可以得出“待付费用”,所以也应该是计算出来的。

不过这个与建模可能没有很大联系?或者是我遗漏了什么类?感觉从用户输入得到的应该是“应付费用”和“历史记录”,而“计算已付费用”和“计算待付费用”都是应该有类担负这个职责。希望高人指点。

现在如果将费用类型(“保险费”、“运输费”等等)作为简单属性的话,感觉最麻烦的地方就是在“费用”的“已付”、“待付”等属性与“保险费”、“运输费”之间的正交关系,一旦费用类型出现业务逻辑,这种建模方式将很难进行修改。

Mayday!Mayday!

banq
2010-09-11 08:01
这个需求关键是要搞清楚需求边界,可变和不可变部分。

>费用类型包括:保险费、运输费、上门送货费、仓储费。(需求非常不稳定)

你在这里说需求非常不稳定,是不是意味着费用类型会不断增加变动呢?

>所有费用都有“应付费用”、“已付费用”、“待付费用”三项

那么这一段是否可以认为是需求的不变部分呢?

有了可变和不变区分,那么依据模式教给我们的定律:可变用继承或接口拓展,不变进行封装。估计如何建模你已经大概清楚。

icethor
2010-09-17 13:01
2010年09月11日 08:01 "banq"的内容
可变用继承或接口拓展,不变进行封装 ...

可变用继承或接口拓展大概明白了,但是“不变进行封装”是怎么做?还望详细告知。

另外昨天刚刚想到的,费用类型与已付应付,应该是play role还是is a?

yananay
2010-09-18 00:07
可以使用领域建模的思路来分析一下。

看了需求,可得出核心的业务是 “运输” ,或许它是一个实体,或者它是一个实体的动词,暂时不知道。

围绕着“运输”,会有 “费用”, 而每个“费用”,又有三个属性:应付,已付,待付。

从以上的简单分析来看,可能存在两个领域模型:运输,费用

同时,一个“运输”,会对应多个不同的“费用”。

感觉就是这样,没多复杂?

freebox
2010-11-09 15:48
同意楼上,因为楼主说了对于费用没有差别,仅仅名字不同,只要一个名字域就能区分了,不需要过度设计。

作为补充,我认为费用还应该包括发生时间这个域。

funjohn
2010-11-10 20:45
朋友 看你说的东西我大概猜想了一下。

你是在给一个物流公司做管理软件。

发货站到 最后到达站 可能会有到付款 或者货到付款 也有些可能是发到仓库 然后等收货人到某个时间去提货。

我不知道该怎么去设计,但是我建议你先搞清楚这个公司的整个运输流程。

因为可能会有到不了得地方 而转发给其他的物流的情况发生 所以就很复杂了。

如果整个业务流都没弄明白的话就这样来设计 你就是想破头也不可能设计出一个以后都不用改动只用添加模块的设计方式。

所以我建议 你不要着急设计 而且先搞清楚 运作方式 和支付流程。

分细 分小 越细 越小 越好。

banjiancy
2010-12-17 00:04
确实是一个复杂的系统,也可能是我想的过于复杂;

从你描述上主要是想解决货物运输费用的问题,并且业务规则比较多切易变

我觉得应该从整体考虑这个问题,以下是我的观点:

把货物运输费用拆开来看既:

1 货物系统(产品)

2 运输系统 (shippment 装运),如果有库存就比较麻烦了(还要设计库存管理模型)

3 费用系统 (计费)

以上可以称之为系统也可以缩小为模块,总之是要将规划业务范围。

我理解的业务流程为:

1 客户(party)订购(order)末种(产品)

2 客户(party)在订单(order)上注明(dec )货运方式(shippment method)、地点(联系机制contact mechanism)、付款人(party)、收货人(party)等信息,并确认订单项(order item);

3 系统(计费系统)通过订单项(order item)计算相关费用

4 付款人( pay party,在一个订单中有不同的角色)通过支付工具(payment method)进行付费

这样基本的模型就出来了,当然有很多遗漏(由于我没有整体需求)

这里产生费用的地方有两处:1 产品定价 2 货运方式 3 联系机制(contact mechanism这个是一个高度抽象,例如同城、异地这个也可以是收费的纬度)

现在解决你说的费用状态

资金如何表示:

账单(invoice ) 、支付(payment ) 账单驱动一笔支付(我是这么理解,先有账单再有支付)

用应收/应付账单表示每笔货运的支付情况,这里主要是应收应付的概念

例如应付账单可以用一笔支付进行核销,这时这笔应付账单状态从“应付费用”转变为“已付费用”

遗漏了一个重要概念 订单(order)是和账单(invoice)相关联的,order 又与shippment 关联

这几个模型都有状态管理。

这样就能看出货运的收费情况(模型比较大想都说清楚比较困难),

(应付费用与待付费用可能也有特殊性,但是我目前还没有捕获到,比如计时、提醒等等。)

这个问题也好处理:

先说待付费用,现实中一般的客户是不能待付的吧,可以选择挂帐来处理,挂帐的方式有几种,给客户开立挂账账户(billaccount),如果没有账户管理模型可以就用一个invoice 状态管理(这个不建议,业务概念不对)

应付费用和待付费用可以每日进行抽取归类,之后根据企业规则选择处理方式,例如你说的计时(为什么计时你要搞清楚是不是为了收滞纳金,如果时那你就要根据滞纳金补一笔invoice 并把账单发给客户。提醒就比较容易了,在模型联系机制上记录客户相关信息,例如邮件、电话等)

统计我就不细说了这些模型在数据库中映射好,根据规则进行查询就可以了

这里我没有说产品模型,这个范围比较大,不过考虑你的需求用产品特征、产品定价基本可以搞定产品范围内的费用情况,再结合货运方式、客户类别、联系机制 这些纬度很容易配置费用。

模型总揽:

party 、 order、 order item 、shippment 、shippment item 、shippment type (这个使用时要高度抽象,别用一个type 字段表示它这里你见到的type可以理解为该模型子类的概念,可以和 Shippment attribute 联合使用,既不同的货运类型有不同的货运收费属性 ) invoice 、 payment、 contact mechanism、billaccount(账单账户)、product 、product category (产品类别,这个我没有介绍从名字上可以看出) 、 product feature 、product price 、(payment method (不同的支付工具可以设置打折等等处理方式,例如现金打8折等)

希望能对你有所帮助。

heyu198496
2011-01-13 13:32
你说的保险费、运输费、上门送货费、仓储费 只是费用模板, "需求非常不稳定" 只是模板可以添加的, 但是在运输过程中,需要通过这些模板来产生实例.也就是发生了具体的费用.不知道我描述清楚没有

猜你喜欢