关于业务规则

              
lxitgto 14-05-08

按照对DDD的理解,一般使用规约模式实现内禀的业务规则。但有些业务规则可以体现为对其他聚合的查询。
而对仓储的调用一般都放在应用层,而这样会造成部分业务逻辑散落在应用层。请问大家有没有好的办法处理?

附上一个订单系统例子,当用户提交订单后,应用层的处理流程如下:

1、开启一个事务
2、调用account的仓储按照account id查询并返回相应的account对象
3、调用Order的工厂方法,创建一个新的Order对象
4、调用下单的业务方法并将account与order对象传进去
5、该方法返回成功后,保存并提交。结束事务。

以上过程中,下单相关的检查(业务规则)一般写在业务方法或order的工厂方法中(使用规约模式? or not)

现在我们新增一些业务规则,1、下单时需要检查要购买的商品是否有货 2、按该商品的类型检查是否享受折扣
增加之后,应用层的处理流程改变如下:

1、开启一个事务
2、调用account的仓储按照account id查询并返回相应的account对象
3、调用商品的仓储按照商品名或id查询并返回相应的商品对象
4、调用折扣信息的仓储按照该商品的类型查询并返回布尔值
5、调用Order的工厂方法,创建一个新的Order对象
6、调用下单的业务方法并将account与order对象传进去
7、该方法返回成功后,保存并提交。结束事务。

从以上例子来看,这些可以使用仓储条件查询实现的业务规则如何放到Domain层去?有没有好的方法可以提高?谢谢!
[该贴被admin于2014-05-09 06:23修改过]

banq
2014-05-09 06:28

首先要确定Order是聚合根,那么业务规则应该封装在聚合根所在的聚合中,也就是说规约模式是属于一个聚合的。

上面的步骤前后调整一下:
原来是:
3、调用商品的仓储按照商品名或id查询并返回相应的商品对象
4、调用折扣信息的仓储按照该商品的类型查询并返回布尔值
5、调用Order的工厂方法,创建一个新的Order对象
6、调用下单的业务方法并将account与order对象传进去

调整为:
3、调用Order的工厂方法,创建一个新的Order对象
4、调用Order的下单的业务方法并将account与order对象传进去
5. Order的下单方法中,首先执行下单前业务规则检查,也就是规约模式,将业务规则检查(可以使用SQL这样的DSL)发消息给仓储层。
6、调用折扣信息的仓储按照该商品的类型查询并返回布尔值消息给Order。



lxitgto
2014-05-09 11:47

你的意思是规约方法可以直接调用仓储层么?但是规约是写在Domain层的,这样是否不符合DDD的思路?

lxitgto
2014-05-09 11:49

还是说规约返回查询条件?然后在应用层传递给仓储?

banq
2014-05-09 14:09

2014-05-09 11:47 "@lxitgto"的内容
规约方法可以直接调用仓储层么 ...


请注意,我上贴写了"发送消息或事件驱动"仓储层做事。

领域层和仓储层之间一定要有事件或消息框架支持,否则领域层无法命令仓储层做事,因为不能直接调用,也不能通过应用层调用仓储层。

2Go 1 2 下一页