战术设计分析和交易域依赖准备工作

• 交易域名业务流程熟悉
• 针对交易域进行战术设计分析
• 核心域上下文的依赖准备工作

业务流程演示

• 视频一： 货道售卖机购物流程演示
• 视频二： 无人货柜机（柜门机）购物流程演示

针对交易域进行战术设计分析

在战术分析时，我们已经把系统中的限界上下文分析出来了，我们需要先把限界上下文画出来，包括交易上下文、支付上下文、商品上下文、设备上下文以及外部的微信支付上下文和商品中台上下文。

在分析的过程中，我们首先还是从角色出发，但是当我们从角色出发，引出了系统中的一些关键对象之后，我们就需要考虑这些对象它的状态变更、构造是否需要系统中其它的对象来提供数据，然后就要思考这个对象它的状态发生变化是否会导致系统中其它的对象状态发生变化，然后在它们之间建立关联。对象的状态变更导致另外一个对象的状态发生变更，可以是通过发送命令的方式，也可以是通过事件通知的方式。

弹出商品就是一个命令通知的方式，出货失败就是事件通知。事件通知的具体方式可以是通过 API 调用来通知，也可以是事件发布和订阅的方式来通知。

比如微信支付上下文通知支付上下文通知支付的状态，就是调用支付上下文提供的回调接口，而系统内部的订单、支付或者其它对象之间，如果是异步通知，就会通过事件发布/订阅的方式来完成。

这样我们就可以把各个上下文需要提供的服务接口给定义下来了。

比如当一个 对象需要为其它对象提供数据的时候，就需要一个查询接口；当一个对象通过命令方式去影响另外一个对象的状态时 ，就意味着这里的边界就存在着一个命令接口；

如果是通过事件通知的方式来影响另外一个对象的状态变更，就存在着事件的发布/订阅，通过战术设计的这种分析，为后面即将进行的编码工作就打下了良好的基础。

战术设计分析—对象间关系

• 一个对象为另一个对象的状态变更提供数据；所谓对象的状态变更可以是一个对象的创建；可以是一个已存在的对象它的状态发生了变化。
  • 售卖机商品对象 类是用户在选择商品之前在售卖机上看到的商品列表，首先它需要的是售卖机里面的商品库存，所以就需要售卖机商品库存对象为它提供数据；此外，我们拿到了售卖机的商品库存，要展示商品的话，我们还需要通过它的商品 id 去获取商品的信息；商品信息和售卖机商品库存就需要有关联，商品信息和售卖机商品库存为售卖机商品列表对象提供数据
• 一个对象的状态变更导致另一个对象的状态变更
  • 当订单创建出来的时候，支付上下文的支付对象需要感知到订单状态的变化，从而开始支付流程，也就是说，订单状态的变化会影响到支付状态的变化，订单到支付对象就会有一个关联；此外，当支付对象的状态发生变化时，比如支付完成/失败，这个状态也会通知到订单，引起订单对象的状态变化，所以也会有从支付对象到订单对象的关联。

在战术设计的过程种，就是要充分挖掘对象与对象之间的两种关联。

我们通过对象与对象之间的箭头表示这两种关联，这是相对于战略设计阶段的领域故事陈述法进行分析的思路上的主要调整，我们的重点不再是围绕着用户和领域中的其它角色以及从这些角色出发的活动来进行分析了，而转变到挖掘领域中的对象和对象之间的关联。

售卖机扫码支付购物

针对售卖机扫码支付购物这个用户故事，首先，用户还是需要在售卖机上选择他要买的商品，这个时候我们需要进行细化，因为用户在选择商品之前，要查看售卖机上的商品列表，售卖机商品列表的数据的创建需要售卖机商品库存（设备上下文）和 商品信息（商品上下文），商品上下文的商品信息是由客户那一侧的商品中台中得到的。

接下来就需要到货道售卖机上选择商品，选择商品之后，货道售卖机的状态就会发生变更。因为这个时候需要进入交易状态，来处理当前的交易，在当前交易取消或者完成之前，它是不可以处理其它交易的。否则会有问题。此时货道售卖机会进入一个锁定的状态，我们称它为交易状态。货道售卖机进入交易状态，会导致领域中创建一个新的对象 — 订单，所以货道售卖机会关联到订单，订单对象的创建还需要用户所选择的商品的商品信息。

订单的创建又会导致其它的对象的状态发生变更，订单生成之后，接下来就需要支付了，订单状态的变更需要传导到支付上下文，会创建一个新的支付对象，支付对象包含了支付平台（支付宝、微信）、订单信息（订单的id、总价等）、支付二维码（需要支付平台提供预支付交易链接，根据预支付交易链接生成交易二维码）等关键信息。

接下来用户就要去扫描支付二维码，当付款完成之后，微信支付上下文会把支付完成这个事件通知到支付上下文的支付对象。支付对象的状态也会发生变更，支付状态的变更就会导致订单状态的再次变更，订单会进入支付完成状态。所以，支付对象会有个箭头连接到订单，表示支付对象的状态的变化也会导致订单状态的变化，订单在支付完成之后就会触发货道售卖机弹出商品，订单的状态变化，也会导致设备上下文的货道售卖机的状态发生变化，同时也会导致交易上下文的货道售卖机的状态发生变化。

设备上下文的货道售卖机有可能会出货失败，也有可能会成功，当出货失败的时候，出货失败的事件一定要通知到交易上下文的订单，订单的状态会再一次发生变化，订单的状态会进入到取消的状态，订单取消状态也需要通知到支付对象的再一次变更，从而触发退款。

除此之外，还需要一个超时控制机制，当用户迟迟不进行付款的时候，我们需要自动取消订单。

柜门机免密支付购物

用户首先扫码二维码请求开门，扫码这个动作其实是请求打开了一个小程序，也就是交易小程序，小程序会去访问交易上下文的接口，如果用户是第一次扫码的话，请求里面并没有携带我们需要的身份认证信息，所以交易上下文会返回错误码；小程序拿到错误码之后就知道需要先去注册和登录，也就是访问用户上下文相关的接口；如果这个用户之前没有签署过微信支付免密扣款的支付协议，用户上下文就会通过响应告知小程序它会去调用微信相关的接口签署支付协议，协议的签署过程是发生在微信支付上下文，签署完成之后微信支付上下文就会把相关的结果通知到用户上下文，会引起用户账号状态的变更。签署完成之后小程序会再次触发登录的动作，这个时候用户上下文就会把登录凭证返回给小程序；

登录完成之后，小程序会再次发起打开柜门的请求，这个时候交易上下文认证了用户的身份之后就会发送命令到设备上下文，从而让设备上下文中的货柜机，打开柜门；这个时候用户就会取走商品，关闭并且锁定柜门，柜门锁定之后，设备上下文的货柜机的状态就会发生变化，这个变化会引起交易上下文货柜机的状态变化，会结束这次的交易，重新进入待命状态，同时也会触发系统生成一个订单对象，订单对象的生成也会导致支付上下文支付对象的生成，同时会向微信支付上下文请求扣款，扣款完成之后也会通知到支付上下文，导致支付上下文中的支付对象状态发生变化；同时也会导致交易上下文的订单进入结束状态。