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

模块化单体范式（The Modular Monolith Paradigm）

适用场景

• 将大型代码库组织为边界清晰的模块
• 团队希望获得微服务级别的边界划分，但又不愿承担分布式系统的复杂性

不适用场景

• 系统已作为微服务部署
• 应用规模极小，引入模块边界反而增加不必要的复杂性

何时采用该范式

• 当你希望团队拥有类似微服务的自治能力，同时避免分布式系统带来的运维开销时。
• 当内部模块间错综复杂的依赖关系拖慢发布速度时。
• 当前单体架构更易于运维，但未来明确需要演进为基于服务的架构时。

落地步骤

1. 识别模块：依据明确的业务能力或领域驱动设计（DDD）中的限界上下文（Bounded Context）来定义模块边界。
2. 封装内部实现：利用语言级可见性修饰符（例如 public/private）、独立包（package）或命名空间（namespace）等方式，隐藏各模块的实现细节。
3. 暴露公共契约：每个模块应通过明确定义的门面（facade）、API 或事件对外提供功能；严禁模块之间直接访问数据库表或调用对方内部实现。
4. 保障架构健康度：编写自动化测试，在检测到被禁止的跨模块依赖或包引用时使构建失败。
5. 规划持续演进：持续追踪变更耦合度（change coupling）和部署范围等指标，为是否及何时将某模块拆分为独立服务提供数据支撑。

关键交付物

• 一份架构决策记录（ADR），明确模块边界，并规定共享代码的使用规则。
• 每处模块交互点的正式契约文档（例如 OpenAPI 规范、事件 Schema）。
• 自动化的依赖检查机制，以及为各模块配置的专属 CI/CD 流水线任务，以强制执行边界约束。

风险与应对措施

• 退化为“一锅粥式架构（Big Ball of Mud）”：
  • 应对措施：若缺乏严格管控，模块边界必然逐渐瓦解。须将任何边界违规视为构建失败错误，并在代码评审中保持高度纪律性。
• 共享数据库热点问题:
  • 应对措施：共享数据库上的高竞争可能成为性能瓶颈。应明确数据表/Schema 的归属权，通过视图（view）限制数据可见性，或采用数据复制策略降低模块间耦合。

故障排查

常见问题

技能未加载
检查 YAML 前置元数据（frontmatter）语法及必需字段

超出 Token 限制
采用渐进式披露（progressive disclosure）策略——将细节内容移至模块中

模块未找到
确认 SKILL.md 中声明的模块路径是否正确

具体组件

以下术语指代该范式落地时实际出现的具体工具与抽象概念。它们并非强制依赖项，也不属于技能 tools: 前置元数据字段所声明的内容（该字段专用于 Claude Code 的工具调用限制）。可在架构讨论中参考此列表，消除术语歧义。

• dependency-analyzer —— 模块依赖关系图构建工具，用于识别非法依赖边
• module-boundary-enforcer —— 在模块跨边界导入时使构建失败的工具
• refactoring-planner —— 根据模块提取就绪度（extraction-readiness）进行排序，辅助未来拆分决策