架构模式是一份按项目复杂度做架构决策的指南，用于在选型、规划战略性重构或评估模式取舍时提供思考框架，本身不绑定任何具体模式。
用途：判断何时该引入架构、何时保持简单；按项目复杂度选择架构方式；规划战略性重构（模块边界、分层）；理解前端与后端架构的差异；评估架构取舍。
主要能力：
- 复杂度驱动。小项目（1-3 人、少于 10k 行）：保持简单，目录结构加代码约定即可，避免分层架构、DDD、Clean Architecture 等过重方案。中型项目（4-10 人、10k-100k 行）：模块化架构，明确模块边界，每模块单一职责并分层，可考虑 Clean Architecture 提升可测性。大型/企业级（10+ 人、超过 100k 行、多团队）：需要完整架构方案，严格边界、领域驱动模块、为可测性采用六边形结构，复杂业务领域可考虑 DDD。原则是先简单，痛点出现再上架构。
- 识别痛点信号：文件超过 500 行且职责混杂、改一个功能破坏无关功能、单测需要 5 个以上 mock、新人两周内无法完成首次贡献、同一 bug 在多处重复修复。
- 区分前后端关注点：前端关注组件层级与组合、局部与全局状态边界、数据获取与缓存、按路由拆分代码；后端关注请求/响应流程分层、业务逻辑与基础设施隔离、数据库访问模式、API 契约设计。常见误区是把后端模式（仓储、用例）套到简单前端上。
- 区分战略与战术重构：重命名、提取小函数、内联变量属于战术，应使用 code-refactoring 技能；定义模块边界、分离分层、提取整个模块、重设依赖属于战略，即本技能范围。
使用方式：先判断项目规模与前后端场景，再按决策树选择路径；需要具体模式知识时转用对应技能，如 solid、clean-architecture、domain-driven-design、hexagonal-architecture、screaming-architecture、result-pattern、dry-principle、mediator-pattern、composition-pattern、state-machines-pattern、circuit-breaker-pattern、sidecar-pattern。资料给出仓储加服务层的示例：控制器校验输入并调用服务、服务负责业务规则、仓储负责数据访问，接口定义在应用层、实现在基础设施层，便于测试注入内存假实现。
限制与边界：不用于学习具体模式、不用于战术重构、不用于代码评审；避免过度设计、设计不足与过早抽象。官方未提供具体安装方式与收费信息，暂未提供。