一般电子商务网,有在线支付功能,有的支付多种支付方式,电子商务网开发需要对支付方式做一个维护,
就是说,我可以动态的增加,删除,修改支付方式,前台网页显示这些支付方式(以便客户支付时可以选择),
假设有这样的关系: 一种支付方式(由于前台显示的需要而添加一些额外的信息)对应一种支付接口(比如
"支付宝"),支付接口(比如"支付宝""支付宝")它支付多种货币交易,但是选择这个支付接口的支付方式不
只需要其中的一种或者几种货币,就是支付方式所支付的货币是从支付接口里选择,是支付接口支持的货
币的一个子集,支付方式与货币是一对多的关系,支付接口与货币也是一对多的关系,前者关系受后者关系
的限制.
支付方式与支付接口是一对一的关系,货币如果作为它们的关联类,好像不合理,如果用面向数据库的思维,我可以在数据库里建两张表,一张是支付方式与货币的一对多的关系,一
张是支付接口与货币的一对多的关系,代码里只要在支付方式选择支付接口时,选择该支付接口支持的货
币,然后把对应的货币插入到数据表里.
如何来理清他们的关系?谢谢.
想用DDD,并不是一件简单的事,自认为看了不少这方面的书,该有个突破,但还是找不到突破口,找不到一个切入点.想开始,然而脑种一片空白,思维还是在有限的空间挣扎.
>支付方式与支付接口是一对一的关系,货币如果作为它们的关联类
用对象方式考虑，必须注意高聚合，也就是两者关系是否紧密，支付方式如果是一个对象，必然有一个支付接口的实现，这应该属于严格的隶属关系。
那么，下面主要考察它们俩和货币关系，货币应该属于支付接口的一个重要属性，支付接口和货币是一对多关联。
没有必要再设计将支付方式和货币的关系，否则就真成了一个蜘蛛网，或者象猫追自己的尾巴一样。
如果你需要确定某个支付方式支持哪些货币，那么就顺藤摸瓜，从支付方式找到支付接口，再找到对应的货币关系。
某次网上支付活动，必然会选择一个支付方式，以及相应的货币，这些信息是记录在“支付信息”这个对象中，支付信息又是嵌套在订单中，或者与订单有1:1关系。
重新梳理了一下业务逻辑,下订单,支付,都是围绕"购物"这个活动,可以把它"购物"作为一个用例,会员启动这个用例.完成"购物"需要以下业务活动:用户选择商品,并下订单,然后再支付,并且网站只支持款到发货,所以我们必须对订单和支付情况的状态进行跟踪,用户也可以对自己的订单状况进行查询.网站支付多种支付方式,比如网上银行(招商,工行等),汇款,第三方支付接口.支付还可以混合使用代金卷,和积分抵扣.最后还要考虑会员等级折扣.在最后完成了支付活动,必须对积分进行更新.积分是根据订单折扣之前的商品价格总和来算.现在的业务算是比较复杂.
下面是我的一些分析:
根据前面的业务:可以抽出一些比较重要的概念,"用户(member)","订单(order)","支付(payment)",之前我提到了支付方式和支付接口,后来想了一下,这是同一个概念就是"支付",为了完成"支付"这个功能,我有不同的支付方式,就是有不同的实现,这里可以用一个"支付接口",封装它的实现.关键是这里有比较复杂的联系,"支付(payment)"在实际中是由"用户(member)"执行的,但是,必须是有了"订单(order)"之后还有"支付(payment)",这里有一个先后的关系.现在考虑支付实现,根据彭老师的建议,这里抽象一个"支付信息(payINfo)",让它负责记录支付情况,比如我消费了多少积分,我选择了什么支付方式(可以混合支付),这里有一个比较迷惑的地方是:谁用"支付接口",是"用户(member)"还是"订(order)",还是其它,如何更真实的反映领域,请各位指点迷津.谢谢.
>谁用"支付接口",是"用户(member)"还是"订(order)",还是其它
两个都不是，是"支付(payment)"，而"订单(order)"和"支付(payment)"则是一个关联关系。
从实际案例中找出正确的关联关系，支付接口不可能和用户有关，因为用户使用太多模型对象了，不可能都和用户挂上关系， 支付接口也不可能直接和订单发生关系，因为订单不只是"支付接口"一个信息，还有支付其他信息如支付多少钱，是否足够等等，而这些支付信息和支付接口一起应该包含在"支付(payment)"这个对象中。
谢谢!但,我的概念上出现了断层,是否理解上出问题了,根据您的建议,建了这样一个模型,(可惜没权限上传图片),我描述一下:
用户(member)"和"订单(order)"的一对一的关系,"订单(order)"和支付(payment)"有关联,然后支付(payment)"组合了"支付接口(pay)"和"支付信息(PaymentInfo)"两个对象.感觉还是有点不对劲.
这是整理的一份设计图,请各位指教.
时序图,我想到的是这样:
[该贴被fety07于2007-10-29 11:23修改过]
积分规则怎么和payment发生关联呢？当然支付以后才会有积分，但是，这里的支付是指支付活动，而不是支付模型对象，这些需要通过一个活动moment-interval 也就是Service来实现。积分规则和payment没有本质联系。
对象设计一个原则就是：高聚合，低关联，找出本质联系，能不用关系就尽量不要用关系。松耦合是一个设计目标。
还有你的payInfo和Payment是什么意思？好像payInfo除了Payment是空的，那么就将payInfo和Payment合二为一。
谢谢,经您这么一指点,脑子里的一些原则活起来.
难怪我自己都不喜欢这个模型,老感觉有问题.
存在这样业务:顾客下订单,如果可以用积分换购的话(积分是从CRM系统取得),顾客输入要换购的积分,如果还有电子购物券也可以抵扣.
之前我这样考虑的: 顾客下下订单时,可以取的订单的总价,然后把总价和换购的积分,这些信息给"Payment"这个类,让它来处理支付,以及积分的换算,最终得到积分和一些支付信息,支付信息是用来跟踪订单支付情况得,最终积分还得返回给CRM.我Payment对象作为支付处理中心了,把积分换算这个职责给"Payment对象",违背了单一原则,如果把积分换算这个职责从Payment抽出来,由于支付,积分换算有一个前后关系,我想到用外观模式来处理,
"这里的支付是指支付活动，而不是支付模型对象，这些需要通过一个活动moment-interval 也就是Service来实现。积分规则和payment没有本质联系。",这里一直是我没突破得一点,原来是这样,这个模型还得改.
>"这里的支付是指支付活动，而不是支付模型对象，这些需要通过一个活动
>moment-interval 也就是Service来实现。积分规则和payment没有本
>质联系。",这里一直是我没突破得一点
如果有四色原型这样分析方法，就能非常快抓住本质，关键还是不能用静止的E-R数据关系来思考，客观事物有静有动，是动静结合，相互作用联系的。
正好看到了这篇文章,谢谢,我想继续完善这个模型,还请彭老师及各位赐教
更正一下说法,上面的模型,严格说不是"领域模型"而是"设计图",领域模型"是起一种承上启下的作用,上承分析下启设计,可以说是填补了从领域映射成软件的鸿沟,一般在编程之前脑子里会有一个大概的静态对象关系图,所以很容易直接跳到设计这一步.
[该贴被fety07于2007-10-30 17:30修改过]
>严格说不是"领域模型"而是"设计图",
是一个初步的设计模型，应该说是原型。但是原型和领域模型也没有明显的区分，领域模型也可以从粗糙到细节直至可以用Java代码实现。
再次对模型提炼:
业务中提到"积分换购"和"购物券",是否该抽象为对象,如果是,对象数量将会很多,它们的关系很杂,其实进入对现实中的模拟.这反而对实现是没好处的,还是不能反映本质.
"积分换购"和"购物券",是一种促销活动,"促销"在现实中是"活动",但反映到模型中则是一种业务规则.这里我想抽出一个对象"SalesPromotion",让它负责"积分换购"和"购物券",促销随时都在变,让"SalesPromotion"封装变化.
在上面的交互图中,用"member"对象来协调其它对象来完成"下订单"和"支付"活动,我觉的不妥."member"成了现在中的模拟,在软件系统中不能这样,应该用"Service对象"来协调这些活动.UI直接跟Service对象关联.如果这样,那"member"对象只用来传值吗?
不知道我这样考虑对不对,请教!
