夜市技能（Night Market Skill） — 源自 claude-night-market/archetypes。如需完整体验（含智能体、钩子与命令），请安装 Claude Code 插件。

基于服务的架构范式

适用场景

• 采用领域对齐服务划分的多团队组织
• 系统组件需独立部署的场景

不适用场景

• 规模较小、单团队即可维护的单体应用项目
• 对延迟极度敏感的系统，其中服务间调用开销不可接受

应采用该范式的典型情形

• 团队需要一定程度的部署独立性，但尚未准备好应对大量微服务所带来的管理复杂度。
• 存在共享数据库或大型系统（如 ERP）时，实现完全的服务自治不现实。
• 需为合作团队或外部消费者建立清晰的服务契约（Service Contract）。

落地实施步骤

1. 能力归组（Group Capabilities）：将相关业务功能聚合为少量定义明确的服务，每项服务指定唯一负责人。
2. 定义服务契约（Define Service Contracts）：使用 OpenAPI 或 AsyncAPI 等标准发布正式接口规范，包含服务等级协议（SLA）及清晰的版本管理策略。
3. 管控数据库 Schema（Control Database Schemas）：即使多个服务共享同一数据库，也须为每个 Schema 或数据表明确指定责任人；所有破坏性变更均须经正式评审流程审批。
4. 建立服务中介机制（Establish Service Mediation）：通过服务注册中心（service registry）或 API 网关（API gateway）统一处理路由、鉴权与可观测性等横切关注点。
5. 规划演进路径（Plan for Evolution）：识别架构中的“热点区域”（hotspots），即未来可能进一步拆分为更细粒度服务的关键模块。

关键交付物

• 一份架构决策记录（ADR），明确服务边界、数据所有权规则及协同机制。
• 为每个服务配套的一套契约测试（contract tests）与消费者驱动契约测试（consumer-driven contract tests），用于验证接口稳定性。
• 涵盖部署流程、回滚方案及服务依赖关系的运行手册（Runbooks）。

风险与应对措施

• 通过共享数据库导致的耦合：
  • 应对措施：共享数据库的变更可能在多个服务间引发级联影响。可通过数据库视图（views）、数据复制（replication）或制定正式的 Schema 弃用时间表（schema deprecation schedule）等方式控制变更影响范围。
• 架构退化（Architectural Degradation）：
  • 应对措施：若缺乏强有力的治理机制，该架构易退化为“分布式单体”（distributed monolith）——即一个披着分布式外衣、实则仍高度耦合且网络调用开销巨大的单体系统。应持续监控耦合度指标，并严格执行服务与数据的归属责任制，防止此类退化发生。

具体组件

以下术语指代该范式落地时实际出现的具体工具与抽象层。它们并非强制依赖项，也不属于该技能的 tools: 前置元数据字段（该字段专用于限定 Claude Code 所支持的工具集）。本列表仅用于在架构讨论中消除术语歧义。

• api-gateway —— 单一入口点，负责将请求路由至粗粒度服务，并集中处理跨领域关注点（cross-cutting concerns）
• service-registry —— 服务目录，记录可用服务列表及其健康状态、接口契约等信息
• schema-management —— 共享 Schema 仓库，用于管理跨越服务边界的类型定义