订单模型设计疑问

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

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

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

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

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

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

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

在下疑问是：

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

请各位请辈指点一下。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在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修改过]

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

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

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

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

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

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

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

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

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

说的很有道理。