Night Market Skill — 从 claude-night-market/archetypes 移植而来。如需获得包含智能体（agents）、钩子（hooks）和命令（commands）的完整体验，请安装 Claude Code 插件。

函数式核心 + 命令式外壳（Functional Core, Imperative Shell）范式

适用场景

• 将纯业务逻辑与副作用（side effects）分离
• 通过不可变的领域模型提升可测试性

不适用场景

• 对性能极度敏感的关键路径（hot paths），此时不可变性带来的开销不可忽视
• 纯粹采用命令式风格的代码库，且无计划引入函数式模式

应采用该范式的典型场景

• 业务逻辑与 I/O 操作（例如数据库调用、HTTP 请求）高度耦合，导致测试脆弱且运行缓慢。
• 大量开发时间耗费在重写适配器（adapters）或应对框架迭代（framework churn）上。
• 需要一套快速、确定性的单元测试，这些测试仅操作普通数据；同时辅以轻量级的集成测试层。

落地实施步骤

1. 梳理副作用：绘制系统中所有副作用的清单，包括数据库写入、外部 API 调用、UI 事件、文件系统访问等，并明确将这些职责分配给“外壳（shell）”层。
2. 建模核心逻辑：将业务规则与策略表达为纯函数（pure functions）。这些函数应仅以领域数据为输入，返回决策结果或命令对象作为输出，避免共享可变状态。
3. 设计命令 Schema：明确定义一组数量精简、语义清晰的命令对象，供核心层返回、外壳层解释执行（例如 PersistOrder、PublishEvent、NotifyUser）。
4. 渐进式重构：优先从变更频繁或关键性高的模块入手。为遗留的命令式代码封装适配器，同时逐步将纯计算逻辑提取至函数式核心。
5. 强制边界隔离：通过代码评审与自动化架构测试确保严格分层。外壳层仅负责编排（orchestration）、流程顺序控制及重试机制；核心层严禁直接调用任何框架或 I/O 类库。

关键交付物

• 一份架构决策记录（ADR），详述选用该模式的原因、受影响模块范围以及迁移工作范围。
• 一套针对核心层的单元测试，要求高覆盖率（>90%）且结果确定。在适用场景下，建议采用基于属性（property-based）或基于测试固件（fixture-based）的方式，覆盖更广泛的输入组合。
• 一套针对外壳层的契约测试（contract tests）与集成测试（integration tests），用于验证命令解析的正确性、重试逻辑的健壮性，以及遥测（telemetry）上报的准确性。
• 一组上线指标（rollout metrics），例如部署前置时间（deployment lead time）、外壳层事故率（incident rate in the shell layer）等，用以量化体现该架构演进的实际价值。

风险与应对措施

• 业务逻辑在核心与外壳间漂移：
  • 应对措施：业务逻辑意外地被重复实现或误置于外壳层是常见问题。应在代码评审中严格执行“核心层拥有全部决策权”的检查清单，杜绝此类偏差。
• 与现有框架存在兼容性问题：
  • 应对措施：命令式外壳仍可能需对接框架特有的生命周期钩子（lifecycle hooks）。在启动大规模重构前，应先构建小型概念验证（proof-of-concept）适配器，验证集成方案的可行性。
• 团队对该范式缺乏熟悉度：
  • 应对措施：通过结对编程（pair programming）及内部“午餐学习会（brown-bag）”形式引入该范式。在试点阶段及时归纳常见反模式（anti-patterns），形成文档并用于指导后续开发。

具体组件术语

以下词汇指代该范式落地时实际出现的具体工具与抽象概念。它们并非必需依赖项，也不属于该 Skill 的 tools: 前置元数据字段（该字段专用于声明 Claude Code 工具调用限制）。请在架构讨论中使用本列表消除术语歧义。

• boundary-validator —— 对进入纯核心层的输入进行校验，确保核心层保持全函数性（totality）
• core-test-generator —— 针对确定性的核心层自动生成基于属性的测试
• shell-adapter-generator —— 生成命令式外壳脚手架，完成核心层与 I/O 层的连接与胶合