创建订单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修改过]
OrderLineCollection作成可观测的是一种方式 这些状态检查基本是事前做的,添加完后在发消息检查已经晚了， 反馈意见在同一个消息同步出来，还是另一个消息异步处理，对业务上处理上都不一样 [该贴被clonalman于2012-12-16 11:37修改过]
这个问题还是比较代表性，太简单了没人关心？
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使用一般的集合,则使用一个函数来写相关添加逻辑
本质上还是一个业务建模的问题,
这个只能同步等待或异步完成，有些时候会与实际情况冲突，技术可能会把实际业务限定死，比如，我只有检查有效后才能 order.getOrderLines().add(orderLine)的情况，这是时候order是不知道orderLIne的，也就拿不起来检查了
Order与OrderLine可以随着事件去“旅行”，Order或OrderLine如何知道“旅行”的终点在哪里？有效型检查可能是随着业务的深化而添加的。