领域影响分析与顶层设计

位置：定义期第 2 步。上一步 requirement-and-invariants，下一步 tech-research-and-reuse。顺序与例外见入口技能 single-session-dev-flow。

拿着需求与不变式单，回答三个问题：哪些现有领域受影响，要不要新领域；谁是这一程的重点、次要、连带；系统全局上这些领域怎么摆。产出领域影响分级表和最粗粒度的顶层设计，它们是后面细化、论证、实施、验收的总边界。

下面两节是思维模型 think-orthogonal 在领域上的做法：先拆轴、每条轴找一个拥有者，再按轴交叉出的表逐格分级。分级按的是与本程改动的关系，不按路径。

先找轴，再找领域

分级之前先问现有领域的结构能不能直接承载这个需求，能就没有新领域。先答三问：应然、实然、差异。做法加载技能 think-ought-vs-is。

需求提出时通常带着一个机制、症状或里程碑，不带它所在的维度。问题里出现的那个词多半不是问题所在的轴。先做维度分解，再对领域：

1. 剥掉表面。问这里真正在变的量是什么，什么必须保持不变。
2. 命名轴。逐项问：谁在做（身份），允不允许（授权、策略），在哪里运行（落点、执行环境），哪份工作要持续（会话、工作），谁执行、活多久（运行时寿命），怎样被看见（观察），怎样接线（装配）。每条轴落在一个拥有者。
3. 找到这条轴的拥有者，先读它的现行正文。多数待决事项在这一步消失，因为拥有者已经回答了它。
4. 查耦合。检查答案有没有让一条轴决定另一条轴。常见形式：隔离提供者决定授权范围；一个实例的寿命决定观察挂在哪里；调用方的寿命决定被调用工作的寿命；提交协议的一个细节反过来决定事实归谁。
5. 到这一步才分类剩下的事项：某条轴上没有拥有者的缺口是新设计；同一条轴上两个都自洽的答案交有权者裁决；其余是实现已经设计好的东西。

迷失了轴的信号：问题里带着机制名；一个答案有两个来自不同领域的理由；其他领域的词出现在本领域契约里；A 的寿命决定了 B 的寿命；一个默认值悄悄成了边界；请有权者在不同轴的选项之间二选一，而这些选项并不互相替代。

跨领域的设计怎么分解

一个设计横跨几个领域是常态。正交要求把设计拆成若干份，每一份落在一条轴上并有一个拥有者，合起来才成立的部分单独交给一个组合承担者。

1. 列出设计触碰的全部事实与决定。列事实，不列模块。
2. 为每条事实命名轴并找到拥有者。一条事实只有一个拥有者。找不到拥有者的先记下，不塞给相邻领域。
3. 每个拥有者只用自己的词说明自己提供什么、需要什么。需求方为自己的需求声明端口，实现方实现它；实现方认识端口契约，需求方不认识实现方。
4. 把集成本身当作有拥有者的对象。集成方认识所有参与方，它是协调者、适配器或装配，不是任何一方的内部。
5. 在接缝上写组合保证：谁参加，成立条件是什么，失败归谁。几个局部成功不等于整体成立。
6. 三个检查：拿掉任何一方，其余各方的含义是否仍成立；每一份能否独立使用；是否有一方读取另一方的内部状态。
7. 最后才套依赖方向。正交约束含义和归属，不约束运行时谁调用谁。

四种做坏的样子：合并（几条轴收进一个对象）、涂抹（一条轴的规则散在几个领域各判一遍）、泄漏（内层认识了外层）、假正交（按目录拆开，含义仍耦合）。

方法上的对照加载技能 pstack:principle-model-the-domain。

分级

连带范围靠消费者普查，不靠猜：加载技能 pstack:blast-radius，找出改动会在别处破坏什么，并用运行代码证明关键的一两条事实。

顶层粗粒度设计

只定到总边界，不定内部：参与的领域与它们的责任一句话；领域之间的关系用一张图（上下文图或协作图）；每条不变式由哪个领域或哪个接缝守；组合保证由谁承担。更细的归 detailed-domain-design。

统一语言与领域模型的做法加载技能 mattpocock-skills:domain-modeling。

产出

填领域影响分级表。分级表的路径写进 spec 的责任分级，交付期按它判一个问题在不在本程。填完的判据：每条不变式都能指到一个守它的领域或接缝；每个「新领域」都写了为什么相邻领域承担不了；连带清单来自普查而不是列举。