层次结构只允许向下依赖，及消解表面向上依赖的三种方法

领域间的关系只有三种：若A需要B的数据资源，是数据依赖；若A需要B的计算资源，是逻辑依赖；若把A、B都看作可计算的逻辑资源来讨论先后关系，则是时序依赖。在[[三种平面结构对应平台库框架的不变性选择|层次结构]]中，存在一条强约束：不变部分与可变部分之间，只能有可变对不变的向下依赖，绝不能有不变对可变的向上依赖——因为不变部分在时序上总是先于可变部分确定，若不变部分反过来依赖尚未确定的可变部分，就等于”已知依赖未知”，这与”已知”这个前提本身矛盾，也会破坏由确定性带来的稳定性。但现实中常常会先”同时”识别到两个相互依赖的领域A、B，把它们转置为层次时就会出现两个方向的依赖，此时需要具体消解：若A、B相互依赖的是不同数据，可以把其中一方的数据下沉到另一方，或把双方的数据都抽取到底层Z，使二者都变成向下的数据依赖；若A、B依赖的是同一份数据在不同时间点的值，说明二者本质上共同依赖一个底层数据层，属于可下沉的数据时序依赖；若A、B之间是相互的逻辑时序依赖，可以通过新增一层数据抽象，把向上的逻辑依赖转换成向下的数据依赖。唯一无法用上述方式完全消解的情况，是把嵌套结构转化为层次结构时：核心部分A’因为可预先确知而必须位于底层，但它对外围D..Z（动态增减的数据）仍然存在一个”注册”性质的依赖——这种依赖可以被处理为A’向下依赖一个确定的”注册逻辑”，而非直接依赖不确定的具体数据内容，从而依然保持整体的确定性。可迁移启发：审查一个分层系统里出现的”向上调用”，先分类它属于哪种关系——多数情况下都能靠”数据下沉”或”补一层数据抽象”转化成向下依赖来消解，只有类似插件/回调注册这种天生需要动态感知上层的场景，才需要专门设计一套确定的注册机制来兜底，而不是放任真正意义上的向上依赖存在。

结构图：

flowchart TB
  R["领域间关系:数据依赖/逻辑依赖/时序依赖"]
  R --> Rule["层次结构铁律:只允许向下依赖<br/>(可变依赖不变,不变绝不依赖可变)"]
  Rule --> C1["表面相互依赖的消解"]
  C1 --> M1["不同数据相互依赖→数据下沉/抽取到底层Z"]
  C1 --> M2["同一数据不同时间值→本就共同依赖底层数据层"]
  C1 --> M3["相互逻辑时序依赖→新增数据抽象层,转为向下数据依赖"]
  C1 --> M4["嵌套转层次的核心对动态外围→向下依赖确定的'注册逻辑'"]