通过公共契约扩展 Mobazha

选择正确的机制

• Port：替换 Core 所需能力的一种实现。
• Module：把经过审核的能力组合进一个发行形态。
• Function：定制有边界且确定性的业务决策。
• Controller：协调外部系统或执行外部 I/O。
• OrderExtension：为订单附加带版本的领域数据和生命周期。

应选择只承担一个职责的最窄机制。一个包可以实现多个角色，但每个公共契约只能有一个权威边界。回调不会自动成为 Port，Module 也不是服务定位器。

保留 Core 权威

扩展只能提交声明、决策、观察或证明。Core 校验身份、授权、模式与契约版本、资源绑定、预期状态、幂等性、新鲜度和策略，然后才创建由 Core 拥有的命令或持久事实。

扩展输入
  -> Core 校验
  -> Core 命令或持久事实
  -> Core 状态机
  -> 审计，并通过受限适配器执行外部动作

• 类型化领域契约可以表达需求时，不增加全局通用 Hook。
• Core 保留发布策略、订单状态、支付验证、结算门槛、审计和密钥托管权威。
• 第三方代码不得导入 internal 包、接收完整 Core 对象或访问原始签名材料。
• 扩展不得写 Core 数据表，也不得直接调用内部状态迁移。
• 支付、退款、争议和结算变化必须重新进入带版本和幂等保护的 Core 命令与状态机。

设计规则

• Ports 为窄小、由 Core 定义的能力提供可替换性。
• Modules 提供不可变的启动期组合，并声明身份、版本、依赖、能力、配置、运行类型和生命周期。
• Functions 有边界且确定性，不获得网络、数据库、密钥、时钟或状态迁移权限。
• Controllers 消费持久 Core 事实来协调外部系统，只返回观察或证明。
• 所有模块遵守统一治理，但业务接口保持窄小、类型化和领域化。
• 新扩展点必须有所有者、模式、权限边界、失败语义、幂等与恢复模型、测试和移除计划。
• 不提供全局命名 Hook 总线、运行时可变注册表或万能 Core 服务定位器。

能力与信任门槛

所有激活门槛通过后，扩展能力才可见。源码存在、标识符已知或代码已经链接，都不等于能力已启用。

发行允许列表
  ∩ 契约兼容
  ∩ 已安装或静态组合
  ∩ 已授权
  ∩ 已配置
  ∩ 健康

• 经审核的第一方模块默认静态链接。
• 独立分发或第三方基础设施默认在进程外运行。
• 商家编写的决策规则在该运行时引入后，应进入 Wasm 等受限沙箱。
• 降低隔离等级需要威胁分析和架构决策。

当前实现边界

静态 Order Extension v1 当前已经校验精确契约名称、不可变启动期组合、依赖与循环、能力和接口的一致性，并在缺失能力时失败关闭。它也已经提供只追加的扩展记录、持久生命周期投递、类型化预留绑定，以及重新进入 Core 结算命令的结算证明。

发行允许列表、按租户授权和配置、结构化模块健康、drain、升级、回滚、第三方进程运行时及 Wasm Function 运行时仍是治理目标，不能描述为已经普遍可用。

Collectibles 首个落地案例

• 签名 NFT 元数据成为由 Collectibles 模块生成、带版本的 OrderExtension 声明。
• Token 或库存分配在创建资金目标前通过模块拥有的 ReservationPort 完成。
• 铸造和交付是由持久扩展事件驱动的 Controller 工作。
• 交付证据成为由模块校验的 SettlementAttestation。
• 卖家收款仍由已有 Core 条件结算命令执行。
• NFT、链、铸造、证书和提供方词汇不进入通用 Core API。

Collectibles 用来证明架构，而不是把 NFT 概念提升为万能 Core 抽象。开发期直接切换已经移除产品专用 Hook、结算命令、队列和 FiatMetadata 镜像。

评审新的扩展点

• 明确领域所有者、业务目的、调用者、声明者和授权者。
• 分别对输入、输出、描述符和兼容行为进行版本管理。
• 定义同步或持久投递、顺序、幂等、超时、重试、死信和对账行为。
• 声明能力门槛、权限、敏感数据以及重新进入 Core 状态机的位置。
• 提供迁移、回滚、移除、可观测性、负向测试和一致性证据。

如果这些答案尚不稳定，应把机制保留为私有实现细节，而不是发布另一个通用扩展点。

权威文档