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

说的很有道理。

javaxmler
2007-09-05 12:39
很赞同chen8251 的观点。

我们看楼主的订单其实是采购行为产生的订单,并不是要别人要买楼主的东西,而是楼主要下采购单去买别人的东西,我们一般把它称为订购单。

[该贴被javaxmler于2007年09月05日 12:43修改过]

terry6394
2007-09-07 02:14
>TPrice 有必要存在吗?

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

我觉得Tprice是不是要作为一个属性取决于需求和你对Price的认识。

TPrice存在的话,设计可能更具扩展性

Tprice可能要表示美元,可能是人民币;可能用中文大写显示也可能是阿拉伯数字;

还可能需要定制一些价格策略,比如打折、买二送一什么的。

sagaris
2007-09-10 11:59
比较认同terry6394的说法,我们的系统在价格方面也遇到了一些麻烦,就是当时没有考虑到这些。

javajavajava
2007-10-29 22:54
1 模型中TOrders 与 TSupplier之间应没有直接关系(如有也不是一对一的关系)

我认为是有关联的,下采购单肯定要知道下给谁,而且不会同一张单下给不同的 Supplier。TOrders 与 TSupplier的关系是非常重要的,不能忽视。

banq
2007-10-30 14:46
>模型中TOrders 与 TSupplier之间应没有直接关系

当然应该有直接关系,是一种高聚合,如果一个订单没有订货单位能叫订单吗?恐怕是产品明细单了。

160649888
2007-11-15 15:32
有个问题:当供应商改变他的名字后,客户再查询以前的订单,在现实的订单中显示的应该是供应商更新前的名字吧,而在计算机中查询以前的定单的时候,通过关联关系获取到的是更新后的名字(我想:名字是供应商的一个属性,名字的改变不会影响他本身作为一个实体存在,不会算做一个新实体吧),这个是否和现实有冲突呢?那这个时候该如何处理这种情况呢?我想不明白!

是不是该把供应商的名字拉出来做为订单的一个属性呢?还有价格变动也存在同样的情况,是不是该把所有会变动的元素,都作为订单的一个属性,然后再把订单和各个对象关联起来.那我觉的是不是有属性重复的感觉?

banq
2007-11-16 09:52
>这个是否和现实有冲突呢?那这个时候该如何处理这种情况呢?我想不明白!

你这个问题很好,不过你提的问题属于另外一种解决领域:记录跟踪,也就是说使用计算机对现实中订单等进行记录跟踪,这个可以参考MF的“分析模式”中的Account来解决。

killer
2007-11-17 16:58
我觉得Tprice不应该作为Tparts的关联对象或者属性,而应该作为TOrderItem的一个关联对象,因为商品的价格是会变的,同一种商品对于不同供应商可能价格不同,对于同一个供应商也有可能在不同的两次订购中(即两张订购单中)价格也不同,这里的价格应该是记录当次订购明细的商品即时价格,是订单明细的一个重要信息,这样也有利于以后跟踪商品的价格变化情况。商品对象Tparts即使要和价格对象关联也只能是一个默认价格,而不能作为本次订购单的价格。

jslwn
2008-07-05 15:34
这根本就是一个很简单的问题。非要把它讨论的很复杂,其实大家说的都没错。这就是面对对象的精髓?

usejava
2009-04-17 16:31
不太同意chen8251的观点

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

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

实际业务,一个订单应该对应一个供应商,否则将造成收货后付款的困难。而且,订单产生前应该确定供应商,因为还要确定价格和订货份额分配。

猜你喜欢
2Go