基于领域分析设计的架构规范 充血模型之Service.docxVIP

基于领域分析设计的架构规范 - 充血模型之Service Entity与Service，相爱相宰 好，接上一篇。 既然接受order.cancel()这种模式，那么一个新的问题来了： 全部的命令操作都要变成这样子吗？那已经巨大的OrderService的代码，岂不是只是单纯挪了一个位置，放在Order里面了，除了上面所谓的可读性的优势，那还有什么用？ 并不是，只是一部分放在实体类，其余的命令操作，照旧会接受一种Service来做。所以，我们必定需要一个可以清楚量化的规范，来确定这些行为该放在哪里： 假如一个命令操作，只修改了一个聚合对象内部的相关数据，那么，就归属给这个聚合?比如，订单取消这个行为，需要做的事情有： 订单形态标记为取消 订单变更记录插入一条，“订单取消” 依据我们之前的图可以晓得，这些修改操作，都在这个订单聚合内，很自然的归属给order 留意，我们反复强调了这里是“修改操作”，也就是说，假如需要我们在此操作期间，查询其他聚合的信息，只需不做修改，那就是允许的！就像下面这样： @Entity public class Order{ private OrderStatus status; private String customerName; private User orderCreator; //假定这里是下单用户，省略了many-to-one的配置 //... public void cancel(){ //修改操作1：变更订单本身形态 status = OrderStatus.CANCELLED; //查询用户信息，要记录到订单变更日志中， //这里假如是Hibernate，会直接触发sql查找，假如换成其他如mybatis，则用对应的repository操作即可，总之，是一个纯查询 String userName = orderCreator.getUserName(); //修改操作2：添加一条订单形态变更信息，具体实现省略 createOrderTrack(OrderStatus.CANCELLED,userName); } } 然后，就要从另外一个角度来说了?假如一个命令操作，并且要求是一个完整的事务，修改了多个聚合的数据，那么，需要为这个行为建立一个 Service?而这个Service，不会是一个{领域名称}+Service，而是一个{具体动作}+Service，比如OrderPayService，订单领取，假定有如下动作： 订单形态改为领取中 商品库存对应扣减 用户若使用了优待券，则优待券标记为使用中 这几个操作，是要在一个完整的事务中的，所以我们写在一个Service中 @Transactional public class OrderPayService{ //-----------(1) @Autowired OrderRepository orderRepository; //-----------(2) @Autowired CouponRepository couponRepository; public String execute(Long orderId,Long couponId){ //暂不考虑前置形态检查 //订单属性变更 Order order = orderRepository.getById(orderId); order.setStatus(OrderStatus.PAYING); //商品库存扣减，按之前的假定，一个订单只对应一个商品 Prodect product = order.getProduct(); product.minusStock(order.getQuantity); //-----------(3) //变更优待券形态 Coupon usingCoupon = couponRepository.getById(couponId); usingCoupon.setStatus(CouponStatus.USING); //去买卖中心猎取领取unikey CreatePayResponse payResponse = payCenterApi.createPay(...各种参数...);