saas-arch-diagramslisted

# SaaS 架构图设计 ## 这个 Skill 解决什么 企业 SaaS 类产品在做产品评审 / 范围判定 / 迭代规划时，需要两类截然不同的架构图： 1. **产品架构图（Product Architecture）** —— 产品在更大生态中的定位、面向谁、提供什么能力域、与外部依赖的边界 2. **功能架构图（Functional Architecture）** —— 平台具体功能的完整清单，按层 + 能力域 + 子能力 3 级嵌套 这个 skill 提供两类图的**结构模板、CSS 设计 token、内容组织原则、常见陷阱清单**，让你避开 6 轮以上的反复返工。 ## 触发场景 - 「画产品架构图」「画功能架构图」「按 4 层结构画下功能」 - 「我需要让别人看清楚我们做什么、面向谁」 - 「这个图能不能区分一下哪些功能是哪个端」 - 「按能力域分类一下」「按子能力做嵌套」 - 「product architecture diagram」「functional architecture for SaaS」 ## 两类图的根本区别 | 维度 | 产品架构图 | 功能架构图 | |---|---|---| | 回答问题 | 我们做什么、面向谁、与下游的边界 | 平台具体有哪些功能模块 | | 视角 | 自上而下看生态 | 自内而外看实现 | | 主轴 | 用户 → 应用 → 能力 → 底座 | 端 → 服务 → 数据 → 底座 | | 颗粒度 | 能力域级（A/B/C/D） | 模块级（每个功能一卡） | | 适用场景 | 给老板 / 跨团队 / 外部讲产品定位 | 内部研发 / PM 做范围判定与迭代规划 | | 是否分版本 | **不分** | **不分**（全局功能视图） | ## 不可违反的原则 读图者最容易抓出来的 6 个"硬伤"，做之前先内化： 1. **不要分版本** —— 架构图是全局视角，"v0.1 / 远期 / 未来" 这类标记一律不要出现。版本规划放 roadmap / PRD。 2. **不要省略合并** —— `④-⑧ 高阶节点` 合并为一卡是为了视觉省事，违反"内容逻辑"。8 个节点就要画 8 张卡。 3. **端的定义要纯粹** —— "端"是用户使用的客户端，**只能是**：运营端 / 供应商端 / 客户端 / 管理端 / 第三方平台。**绝不能**包含「后端」「业务服务」「数据」这种技术语言。 4. **服务和页面不能混** —— 评测任务列表（页面）和评测流水线 controller（服务）属于不同层次，硬放一起会让人看不清。 5. **能力域不能平铺** —— 域内功能必须再分子能力，3-7 个并排卡片堆在一起没有层次。 6. **不要为了对齐而留空白** —— grid 等宽分配 4 列时，某列卡片少就空一片。要按内容动态分配 col-span。 ## 产品架构图：4 层视图 ### 结构 ``` ═══ L1 用户与场景 ═══ 谁在用 / 在什么场景下用 ═══ L2 应用层端 ═══ 端的 UI 入口 ═══ L3 能力域 ═══ 4-5 个 capability domain（A/B/C/D/E） ═══ L4 平台底座 ═══ 执行 / 观测 / 通信 / 数据治理 等共用基础 ⇩ ═══ 外部依赖 / 下游 ═══ 下游消费方（如本平台是 下游聚合子系统则下游是 API 网关） 横切