Skip to content

[design] P1: 多层 Arc<Config>-only 转发导航壳重设计 ADR(深导航 vs 砍导航) #347

Description

@foxzool

Parent

#314(deep-module epic,P1)

背景

deep-module 审查确认 11 个 crate(workflow/meeting/mail/helpdesk/application/platform/analytics/bot/docs/cardkit/user)的导航链是多层 Arc<Config>-only 纯转发壳:Service→Vx→Resource 每层只 clone Arc 构造下层,零校验/状态/缓存/默认值。用户为 bot().v4().bot().search() 这种空跳付出成本——导航 DSL 形态本可由方法签名零成本表达。这是最普遍的 shallow-module 形态,影响整个导航抽象

#311/#312 已为 user/application 补上门面 accessor(缓解「门面缺 accessor」),但未触及「层本身是纯转发壳」这个根问题。

What to decide(design-gated,非 AFK 实现)

深导航 vs 砍导航——二选一:

  • A. 深导航:保留多层结构,但让中间层承担真实职责(校验/缓存/默认值/日志),不再是空转发
  • B. 砍导航:扁平化,service.bot_search_v4() 直达,消除中间层

Deliverables

  • ADR(docs/adr/):决策 + 理由 + 影响 11 crate 的迁移路径
  • 决策后拆为 per-crate ready-for-agent 子 issue

Blocked by

None — design 可立即开始(需人工决策,故 ready-for-human)

Metadata

Metadata

Assignees

No one assigned

    Labels

    ready-for-humanRequires human implementationtype:refactor架构或接口收敛性重构

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions