订单模型设计疑问

07-08-10 sxdthonda
各位大侠大家好。我想设计一个订单模型。现在设计如图所示:

Torders代表的是订单;TorderItem代表的是订单明细;Tparts代表的是商品;Tprice代表的是价格;Tsupplier代表的是供应商。请大家指点一下。

哈,如果有哪位大侠有好的模型请提供一下,让小弟学习学习。

[该贴被sxdthonda于2007年08月16日 15:13修改过]

banq
2007-08-15 12:28
设计不错啊。

你需要其他给你show他们的模型?是展示他们漂亮的模型图呢(可能五颜六色)?还是其他什么?

模型是根据业务需要来设计的,你没有贴出你的业务需求,而只是告诉我们结果,这就很难了,就象1+1=2,你只告诉我们2的结果,并且用彩笔画了好看的2字,意义不太大噢。

UML图就象AutoCAD图一样,会画AutoCAD的不一定是建筑师。关键是掌握设计思想。

sxdthonda
2007-08-15 12:44
多谢彭老师:)

我是在学习O/R时想自已做一个简单的库存管理软件练练手。基本业务流程是:

操作员下订单,选择供应商,同时录入需要订货的明细。这个可以使用刚开始的类模型。

但我想,当到货入库时,该怎么操作呢?(业务流程是:当到货后,首先点到货数量,然后根据到货数量,做一个入库单,当然还要更新库存数量等信息)。但在些,入库单这个怎么处理呢?想了好久都没办法。

订货单,入库单,以后还要能进行一查询。

在下疑问是:

再设计一个入库单及入库明细类呢,还是把现在的Torder类增加一些属性,同时表示订货、入库呢?

请各位请辈指点一下。

banq
2007-08-15 12:52
>再设计一个入库单及入库明细类呢,还是把现在的Torder类增加一些属性,同时表示订货、入库呢?

这是问题关键,我们曾经讨论过:一个事物必然要包括一个约束问题,只要它符合一个约束,就可以定义它为类/对象,也就是说,一个对象中属性必须是明确标明它的特征,是一种约束。

Torder是订单对象,很显然入库不属于订单的内在属性,不应该被划入订单对象,而应该重新设计一个对象“库单”(可以设计有入库单/出库单两种子类)。

sxdthonda
2007-08-15 14:23
呵呵,一句话点醒梦中人,明白了,多谢彭老师。

banq
2007-08-15 14:30
>一句话点醒梦中人

其实对象设计一点不深奥,它就是我们日常生活的知识,只不过我们原先被所谓专业知识(如数据库分析设计)蒙蔽双眼,还有多少人没有醒悟呢。

yananay
2007-08-15 18:24
TPrice 有必要存在吗?

我觉得应该是 TPart 的一个属性

TOrder 也没有存在的必要吧,有一个 出库Order 和 入库Order 就可以了。

甚至我认为出库,入库成为一个订单的属性更合理。

不然,如果订单分为经理签字和经理不签字2种情况,也设计成2个类?

[该贴被yananay于2007年08月15日 18:29修改过]

[该贴被yananay于2007年08月16日 09:16修改过]

banq
2007-08-16 14:48
模型建立有不同意见是最好的,能够加深我们对业务的认识。

如果TPrice 不是一个很重要的事情,确实应该纳入Torder一个属性,我同意这点。

>我认为出库,入库成为一个订单的属性更合理

可能楼上没有对业务流程有一个熟悉,订单有了以后,工厂根据订单生产出产品货物,产品货物才有出库和入库的概念,因为必须首先放到仓库中保存。

领域建模就应该象这样通过不断讨论加深每个参与者对业务的熟悉。不断迭代,最后找到接近事物本质的模型出来。

最近帮助一家公司查看他们软件项目的招标书和设计书,基本就是将数据表结构字段列出来,然后,大谈Spring Hibernate等框架,这显然是一种畸形的设计书,完全不是OO的,高质量的设计书应该是大量篇幅谈论这个项目系统的对象模型设计,如上述讨论设计过程总结。

yananay
2007-08-16 15:16
原来是这样。。呵呵

那么出库入库因该是货物的属性了。

不过还是提醒楼主,刚刚学习从业务领域进行分析的时候,

很容易陷入对象的陷阱,例如你设计的 TPrice。

切忌,你是为了理清业务而使用对象,

而不是为了对象而使用对象。

zwjsoft
2007-08-16 15:30
>可能楼上没有对业务流程有一个熟悉,订单有了以后,工厂根据订单生产出产品货物,产品货物才有出库和入库的概念,因为必须首先放到仓库中保存。

那将出库、入库作为Tparts商品的属性呢?

banq
2007-08-16 15:48
>那么出库入库因该是货物的属性了。

初步看,好像出入库应该是货物的行为,但是仔细研究,货物行为应该和该产品非常紧密的特征,比如货物是汽车,那么会跑 加速等才应该是汽车的行为,如果将出入库这样一个管理行为加到汽车中,比较牵强。

DDD建模过程中,Evans专门谈了MF的分析模式,MF分析模式是分析中一个经典,其中,有一个模式叫:Inventory and Accounting模式,库存与记帐模式:

很多软件系统主要用于跟踪记录track,比如跟踪钱的流动,从一个企业如何赚到钱到如何花钱,跟踪货物从一个点到另外一个点,从仓库入库,到仓库出库,到发货到客户等等,这些显然有一个共同的特征,我们可以使用accounting and inventory 分析模式思路来解决。

当然,一般小系统没有必要如此复杂,但是accounting and inventory 模式开拓了我们分析思路,开拓了眼界,那么显然,我们要针对货物进行一个入库出库跟踪track了,所以,自然不会将入出库作为货物属性。

相关帖子:

用科学的思维方法指导软件的设计开发

http://www.jdon.com/jivejdon/thread/32520.html

领域驱动设计与模型驱动设计的关系

http://www.jdon.com/jivejdon/thread/32510.html

Hibernate等ORM使用之道

http://www.jdon.com/article/31684.html

[该贴被banq于2007年08月17日 09:03修改过]

sxdthonda
2007-08-16 16:52
太好了,大家的讨论太精彩了,我又学到不少知识。呵呵,已经将Tprice全部归到TParts中了。

chen8251
2007-08-22 17:51
仔细分析一下楼主的业务需求,我想指出这个模型中有以下几个地方不是很正确,或与常规的定单模型相背.

1 模型中TOrders 与 TSupplier之间应没有直接关系(如有也不是一对一的关系)

与定单TOrders关联的应该是TOrderItem,与TOrderItem关联的是TParts,与TParts关联的才是TSupplier.

举个例子,我们要下定单买件衣服,首先我们不应去选择一个供应商(比如选择美国波音公司),之后再去选择这个供应商的商品,因为这个供应商可能并没有我们需要的商品.

当然你可能说我对这个供应商很熟悉并了解他有什么商品,但这仍不是一个好的设计.试想当你需要变更定单中某一个商品时(如不采购波音的飞机,换成空客的飞机),你将需要同时修改定单(具体应该是定单名细),以及维据与供应商的关系.在实际业务中这样的模型是浑沌的开始.

2 楼主的Use case并不适合应用定单模型来设计

  我想用"采购计划"或"采购模型"也许更能表达楼主的业务需求.我们知道 只有在"卖"的一方才存在"定单模型","买"方只有采购计划.

根本原因是误用了模型,所以再讨论把"出库/入库"置入TOrders或TParts中,这已不是妥不妥的问题了,很显然这是一个不好的设计,将与对象毫不相关的属性放入到对象中.另外强调一下,不要把"出库/入库"作为商品(TParts)的属性,就如"在哪里"能作为"人"的一个属性吗,否则"人"会有无数多的属性.

以上是我的一点看法,欢迎大家指正

   

sxdthonda
2007-08-27 12:33
呵呵,上周在北京整整培训了5天!

chen8251 ,你的分析很有理.我是初学O/R自己想设计一个模型.非常感谢大家的宝贵意见.

qujingbo
2007-09-03 20:37
to:chen8251

说的很有道理。

猜你喜欢
2Go 1 2 下一页