数据库服务开发：分层、Session 与事务回滚｜课前预习

这一页只有问题，没有答案。先去真实业务里看一眼，再带着技术上想不通的地方来上课。写下自己的初步判断和依据，不必提前学会全部新知识；不确定的地方留到课堂用代码验证。

第一部分｜业务观察：订单变化与库存变化必须怎样配合

阅读有赞库存变动说明，分别记录下单和付款两类库存处理方式的业务触发点。
阅读未付款订单关闭后的库存回补说明，记录订单动作与库存结果之间的联系，并注明说明适用的库存模式。
顺着这些业务联系往后推：一笔订单成了之后，业务上要核对哪几项账？没成的时候又要核对哪几项？平台内部怎么保证这两头一起生效，页面上没有证据，就写“怎么实现的，待验证”。

只看你自己账号能看到的页面，看到提交订单那一步就停。不用真的买、真的付款，也别去动商家的真订单。截图只留相关字段，把账号、电话、地址、订单号这些个人信息盖掉。

业务触发—订单结果—库存结果—适用条件四列表，以及课程中准备核对的对象。

记录时写清六项：平台或资料标题、链接或 App 页面路径、观察日期、实际看到的内容、自己的判断、还要验证什么。可以附一张去掉个人信息的截图，不附也行。进不去的时候就去读上面那份官方说明，注明“这条是看官方文档得到的”；还是没有依据的，就写“没观察到／待验证”，下次再补，别编。

订单动了，库存就得跟着动；没成，两头都得退回原样——这是业务上的铁律。至于在数据库里怎么让它“一起生效、一起退回”，是今天课堂要动手验证的技术问题。

下面几个问题，是帮你把刚才看到的业务现象，转成业务上明确的要求。你自己的判断和推测请单独标注，别当成平台真发生过的事。

这一段只负责把业务说清楚。 上面这些都是业务上真实存在的要求；至于怎么用技术把它们做出来，是下面第二部分「技术预习」和今天课堂要解决的事。

回看一下上次课你自己的项目和运行记录，先找出跟今天的业务场景有关的输入、处理和输出。下面这些词只是帮你认出课上要解决的问题，不用课前背下来。

写下你的预测、你的理由，还有一个到现在还没想明白的地方。装好环境的同学可以直接用现有代码验证；环境还没弄好的，先在纸上预测一下，不用为了预习专门去装不熟悉的依赖。

你写下的业务和技术问题，会在课上对应的知识点里解答，并配合演示核对；按课堂同名机制小节回看，不重复抄写一份标准答案。

本节只给问题，不提供标准答案。