场景描述：

一群门店给一群园区送外卖，不同门店营业时间不同，不同园区允许外卖进入的时间段也不一样。同时，由于门店与不同园区之间的距离有远有近，所以并不是每个门店都能服务所有的园区，也不是每个园区都能点所有门店的外卖。有的门店可能会因为某些不可预计的原因临时闭店，从而无法按照预期提供外卖服务。

在原来的设计中，骑手没有自己的钱包，所有的资金都是团队管理员通过以下步骤发放给骑手的：

1. 系统先将佣金发放到团队钱包内。
2. 团队管理员通过团队钱包进行提现。
3. 团队管理员根据分配规则将钱通过线下转账给对应的骑手。

当初设计的错误：把门店与骑手团队当作相同的对象来处理了。
其实，门店与骑手团队是不一样的，具体来说，就是这两者与各自内部人员的关系是不同的。

把全部交易参与方都设定为团队之后，发生了新的问题：

某个门店可能突然终止合作。

在我们划分了团队之后，发现还存在一个独立骑手的参与方，但这个角色看起来是多余的。

上线之后立马遇到了问题：

1. 门店有多个员工轮流值班，公用账号的问题。
2. 后续会通过小程序给门店付钱，要控制提现的权限。
3. 实际进行配送的可能不是一个骑手，而是多个人按照目的地来分配任务。
4. 骑手也存在与第 2 点相同的问题。

最开始设计的系统。没有考虑那么多，所以门店和骑手其实是作为系统的基础数来看待的，是系统的一部分。
然后给每个门店分配一个店长，给店长分配一个业务账号，给骑手自身分配一个业务账号。

一个 API 的设计迭代案例…

一个真实的反模式 API 设计案例…

用工具支持 monorepo 模式。