开发记录：Nuxt业务模块与feature目录重构

这篇开发记录用于复盘 M5-15 的背景、目标、执行过程和最终结果。

为什么在 M5-15 补 Nuxt业务模块与feature目录边界

前面的案例已经覆盖了页面、基础组件、SSR、Nuxt 页面数据、状态管理、复杂交互、认证权限、路由壳层、错误隔离、异步加载、Nuxt 运行时边界、Nuxt 响应策略、Nuxt 执行时机、Nuxt 依赖边界、Nuxt 页面编排边界和 Nuxt 接口边界，但在真实 Nuxt 项目里，还有一条会持续穿透这些内容的主线：即使页面分层、composable 分层和接口边界已经变清楚，如果业务模块本身没有成为第一组织单位，代码仍然会被很多技术目录切碎。

只要这条链路没有收口，前面任何一类场景都会逐渐出现问题：

• 同一业务能力散在多个全局技术目录里，很难整体追踪
• feature 私有实现过早升到公共层，导致全局暴露面越来越大
• 页面编排、领域状态和服务端协同虽然都存在，但没有围绕同一业务主线对齐
• 新需求接入时只能继续往公共目录里堆，而不是落在明确模块里

所以 M5-15 选择 Nuxt 业务模块与 feature 目录边界，是为了把“业务主线聚合、feature 私有实现、应用公共层收口、页面模块入口、模块级服务协同”这一条非常常见的横向架构线补齐。

这轮做了什么

这轮主要完成了这些事情：

• 新增 Nuxt 业务模块与 feature 目录案例文档
• 新增 M5-15 任务拆解文档
• 新增 M5-15 详细设计文档
• 更新里程碑、入口、导航与统一框架
• 将 Nuxt 模块组织型案例正式纳入当前方法库

这轮最重要的决策

决策一：先讲业务主线，再讲目录命名

这轮没有把重点放在“目录到底叫 features、modules 还是 domains”，而是放在：

• 为什么业务主线应该成为第一组织单位
• 为什么应用公共层不能继续承接 feature 私有实现
• 为什么页面、store 和接口应该围绕同一业务对齐
• 为什么页面入口应该逐渐退回模块入口

决策二：选自动导入、页面编排和接口边界案例共同作为素材来源

这组素材非常适合作为案例来源，因为它刚好覆盖了：

• 公共入口与私有实现的暴露控制
• 页面业务编排层如何收口复杂度
• 服务端契约如何与页面业务主线对齐
• store 和领域状态如何围绕业务命名

它很适合作为“从页面与能力分层，走向业务模块组织”的过渡案例。

决策三：把页面、状态和服务端协同放到同一个模块视角里

这轮没有把目录组织继续视作表层整理动作，而是把重点放在：

• 页面模块入口如何接住业务主线
• feature 私有实现如何留在模块内部
• 公共层如何只暴露真正稳定的复用能力

这样新案例就能直接挂到当前已经形成的统一框架里。

本轮自测怎么做

这轮仍然只修改文档，因此自测继续聚焦文档完整性：

• 检查新增 Markdown 文件是否生成成功
• 检查本地链接是否全部可解析
• 检查入口页、导航图和总框架是否已经接入新案例
• 检查 M5-15 的任务拆解、详细设计和开发记录是否齐全

本轮结果

M5-15 完成后，当前方法库已经不只覆盖状态、渲染、交互、认证、路由、容错、异步加载、运行时边界、响应策略、执行时机、依赖组织、页面编排和接口治理问题，也开始覆盖 Nuxt 项目落地时的一条基础主线：业务模块聚合、feature 目录边界、公共层收口和模块级服务协同。

这意味着后续如果继续扩展：

• 后台业务系统的 feature 模块拆分方式
• 内容平台和交易链路的模块级服务协同
• 公共层治理与伪复用能力回收
• 页面模块入口与目录可追踪性优化
• Nuxt 项目级 feature 架构治理

都已经有了稳定挂载点。