上线之后立马遇到了问题：
- 门店有多个员工轮流值班，公用账号的问题。
- 后续会通过小程序给门店付钱，要控制提现的权限。
- 实际进行配送的可能不是一个骑手，而是多个人按照目的地来分配任务。
- 骑手也存在与第 2 点相同的问题。
根据实际的情况，我们发现了之前的缺陷：我们错误的定义了门店和骑手方，门店和骑手并不是系统的基础数据，而是系统的交易参与方。
同时，店长等人员只是门店自身雇佣的员工。
所以，我们把门店在结构上往上提一级，同时在骑手之上创建“骑手团队”这个参与方，把参与同一个配送任务的人员归为一个骑手团队。
平台运营人员在创建门店的时候，平台系统隐式的创建一个门店账号。
这个账号包含门店的业务部分和资金部分，但是这个账号并没有明确的登录途径，只有门店的成员可以登录然后参与门店的业务，同时给门店指派一个管理员，管理员可以处理成员管理以及资金的事务。管理员与其他员工除了权限上的不同之外，并不存在其他的本质区别。
门店这个参与方可能遇到的问题：
- 门店可能会换个品牌。
- 门店可能会换个老板。
- 门店可能会老板和品牌全都换了。
因此，需要详细区分以上各种情形，以决定何时应该换个管理员，何时应该销毁并重建整个门店，以避免不必要的数据泄露或者数据纠纷。
骑手团队的逻辑结构类似。
修改之后，产品结构大致如下：
