业务建模:辨析一个Order老问题

创建订单Order后,给订单添加明细OrderLine,有几个方案:
1、order.addOrderLine(orderLine)
2、order.addOrderLine(sku, quantity)
3、order.addOrderLine(product, productVariant, quantity)
4、order.addOrderLine(product, variants, quantity)

辨析模型上的几个不同方法,前端UI设计、后端模型设计有哪些的影响?

前端:
1、对应一个订单添加明细界面?
2、对应一个SKU选择界面?
3、对应一个产品及其规格选择界面(分步完成)?
4、对应一个产品及其规格组成选择界面(分步完成)?

后端:
订单行假设需要有效性检查,库存可用量检查,方法外还是方法内?
这些检查行为需与其他模块(如库存)进行交互,异步还是同步?使用领域事件?

感觉每个方法都有对应的业务含义,比如可能是录入一个明细行,也可能是产品、颜色、尺寸分别选择等,建模时,我们只选择其中的一个还是全部?

其实,还有一个添加OrderLine的方式
order.OrderLines.add(orderLine)这个最通用了,任何业务场景都能使用,缺点是业务检查逻辑都防在领域服务内

不用啊,order.OrderLines.add(orderLine)操作会触发orderLineAdded消息,所有订阅了该消息的服务都能收到消息并给出处理意见,例如库存状态等。
[该贴被gameboyLV于2012-12-15 21:48修改过]

2012-12-15 21:47 "@gameboyLV"的内容
不用啊,order.OrderLines.add(orderLine)操作会触发orderLineAdded消息,所有订阅了该消息的服务都能收到消息并给出处理意见,例如库存状态等。 ...

OrderLineCollection作成可观测的是一种方式
这些状态检查基本是事前做的,添加完后在发消息检查已经晚了,
反馈意见在同一个消息同步出来,还是另一个消息异步处理,对业务上处理上都不一样

[该贴被clonalman于2012-12-16 11:37修改过]

这个问题还是比较代表性,太简单了没人关心?

2012-12-19 09:37 "@clonalman"的内容
这个问题还是比较代表性,太简单了没人关心 ...

Order是聚合根,其对内部对象OrderLine的任何操作都要受其业务规则约束。有效性检查都是在Order的有关add OrderLine方法内。

如发现需要其他模块支持,就再发消息到需要支持的模块,如果那个模块检查完毕,回再发回当前处理队列中,Order只要再拿起检查一下是否一切有效前提条件都OK。

参考 LMAX架构

2012-12-19 13:53 "@banq"的内容
如发现需要其他模块支持,就再发消息到需要支持的模块,如果那个模块检查完毕,回再发回当前处理队列中,Order只要再拿起检查一下是否一切有效前提条件都OK。 ...

1、涉及OrderLine的创建位置和初始化.
2、addOrderLine参数的选择
3、同步或异步(检查非法,addOrderLine抛异常)

下面几个实际是领域服务OrderPlaceService的方法:

order.addOrderLine(sku, quantity)
order.addOrderLine(product, productVariant, quantity)
order.addOrderLine(product, variants, quantity)

领域服务:
OrderPlaceService..addOrderLine(order, sku, quantity)
OrderPlaceService..addOrderLine(order, product, productVariant, quantity)
OrderPlaceService..addOrderLine(order, product, variants, quantity)

而:
order.addOrderLine(orderLine)
order.getOrderLines().add(orderLine)
区别在于orderLines集合是否需要被观察,
如果orderLines使用可观察集合,并被order所观察.
当order.getOrderLines().add(orderLine)触发order执行添加逻辑.
如果orderLines使用一般的集合,则使用一个函数来写相关添加逻辑

2012-12-28 07:00 "@clonalman"的内容
order.addOrderLine(orderLine)order.getOrderLines().add(orderLine)区别在于orderLines集合是否需要被观察,如果orderLines使用可观察集合,并被order所观察. ...

本质上还是一个业务建模的问题,

2012-12-19 13:53 "@banq"的内容
如发现需要其他模块支持,就再发消息到需要支持的模块,如果那个模块检查完毕,回再发回当前处理队列中,Order只要再拿起检查一下是否一切有效前提条件都OK。 ...

这个只能同步等待或异步完成,有些时候会与实际情况冲突,技术可能会把实际业务限定死,比如,我只有检查有效后才能
order.getOrderLines().add(orderLine)的情况,这是时候order是不知道orderLIne的,也就拿不起来检查了

2012-12-28 07:11 "@clonalman"的内容
这是时候order是不知道orderLIne的,也就拿不起来检查了 ...

注意检查前,Order或OrderLine只是事件参数,事件触发是否Order的addLine行为,需要对事件参数进行有效性检查。

这个讨论举例

2012-12-28 08:27 "@banq"的内容
注意检查前,Order或OrderLine只是事件参数,事件触发是否Order的addLine行为,需要对事件参数进行有效性检查。 ...

Order与OrderLine可以随着事件去“旅行”,Order或OrderLine如何知道“旅行”的终点在哪里?有效型检查可能是随着业务的深化而添加的。