落地顺序：被依赖的先走

上级：structure · 邻居：domain-facade-and-ddd-layout · backend-domain-modules

一条落地顺序的规则，同时也是一条关于谁来定这个顺序的规则。

被依赖的那个模块先走。彼此不依赖时，按它们被提到的先后来，然后就开始。

为什么要把它写下来

一次涉及 N 个模块的迁移，有 N! 种可能顺序，而通常只有一条真实约束：有些模块被别的模块读。一旦这条约束被满足，剩下的自由不是一个决定——它是一次被打扮成决定的抛硬币。而把一次抛硬币当成问题递回去，代价是一整个来回，换来一个不携带信息的回答，还让本可以边问边做的活停了下来。

所以这条规则有两半，而承重的是第二半：别再问"下一个做哪个"。 "先做哪个"在存在依赖时才是一个真问题——而那时答案是机械的，所以照样不需要问。

具体怎么走

• 所有别的模块都要读的那个先走：共享词汇、身份类型、错误面。在依赖之前迁消费方，等于让消费方 import 了旧形状，然后被迁两次。
• 两个模块确实互不相干时，顺序就是它们在计划里被提到的顺序。这不是偷懒——这是拒绝在没有判断可用的地方消耗判断。
• 计划要在动第一刀之前把顺序写下来，于是一个中途接手的会话是读这个顺序，而不是重新推导它。重新推导，正是第二个不同的顺序被发明出来的地方。

更一般的形状

这是一个更大立场的一个实例：能推导就别问。 大多数"感觉需要 owner 拍板"的问题，其实已经被某条写下来的原则回答过了——而真正需要人的那些，通常关乎授权（这东西可以被允许做什么），不关乎顺序。顺序是可推导的；许可不是。