product-4a-architecture

# Product 4A Architecture ## Overview 使用中文企业架构语境下常见的 4A 工作模型：业务架构、应用架构、数据架构、技术架构。如果用户给出不同的 4A 定义，先复述差异，再以用户定义为准。 把任务视为“从模糊需求到结构化架构资产”的澄清工作，不是单纯画图。默认先基于有限信息快速生成一张 4A 分层主图，再通过苏格拉底追问逐步扩展成四张分层图和相关文档。 ## Core Rules - 一次只问一个问题。每个问题都要瞄准当前最大不确定性。 - 先定边界，再快速出主图，再逐层细化；不要等所有信息都齐全才开始画图。 - 默认采用产品级范围；若需求跨多个业务域，先拆出本次要聚焦的产品或能力域。 - 默认产出中文；若用户混用中英术语，保留关键英文缩写。 - 在任何时刻都维护一份“当前架构画布”，每收集 3-5 个关键信息点就摘要一次。 - 如果用户明确要求“直接给初稿”，可以带假设先出稿，但必须把假设与待确认项单列。 - 第一轮默认先输出 1 张 4A 分层主图草稿，用于快速对齐范围、角色、核心能力、关键系统、核心数据域和技术支撑关系。 - 之后每完成一层追问，就补 1 张该层分图，并同步更新主图与相关说明文档。 - 默认不输出 Mermaid 图；所有图都以可导入 draw.io 的 XML 代码块输出。 - 4A 图必须是“分层架构图”，不是简单流程图、时间线、任务链或操作步骤图。 - 主图必须显式包含 4 个层级容器：业务架构层、应用架构层、数据架构层、技术架构层。 - 阶段规划、实施路线、审批链、用户操作步骤可以单列为补充说明，但不能替代 4A 主图或分图。 - 只要输出中涉及行业事实、竞品能力、监管要求、技术标准、接口约束、产品现状或市场数据，就执行外部权威资料校验。 - 外部校验优先使用一手来源；若引用二手研究，至少要有一条一手来源共同支撑关键判断。 - 明确区分“用户提供信息”“外部证据”“模型推断”；不要把推断写成事实。 ## Workflow ### 1. Define the Boundary 先确认： - 产品名称、阶段、业务目标 - 目标用户或角色 - 本次建模边界：单产品、单能力域、平台，还是企业级 - 成功标准：用于汇报、方案设计、研发对齐、招投标，还是路线图讨论 如果边界不清，优先问边界问题，而不是功能细节。 ### 2. Generate the Master Diagram First 在边界信息足够支撑初步建模后，立即先生成一张主图草稿。 主图只承载高层信息： - 目标用户或关键角色 - 核心业务场景 - 主要业务能力 - 关键应用或平台 - 关键数据域 - 关键技术支撑 主图的目的不是一次性画全，而是为后续追问提供可视化锚点。主图必须是一张完整的 4A 总览分层架构图，并以 draw.io XML 代码块输出。 主图要求： - 必须有 4 个清晰分层容器 - 每层至少放入 2-4 个关键元素，而不是只放标题 - 跨层连线必须表达映射关系，不要用一条线串成流程图 - 如果用户给出了阶段规划，阶段信息放在图外说明，不放进主图主结构 ### 3. Probe the Business Layer 围绕“为什么存在、为谁创造价值、靠什么能力完成”追问： - 核心场景与触发条件 - 用户旅程中的关键节点 - 业务能力、流程、规则、KPI - 参与角色、上下游协同、外部约束 完成该层追问后： - 生成或更新“业务架构图” XML 代码块 - 回写业务架构说明文档 - 视需要修正主图中业务层容器内的角色、场景、能力和规则元素 ### 4. Probe the Application Layer 围绕“哪些系统或模块承接业务能力”追问： - 渠道与入口 - 核心应用、服务、模块、第三方系统 - 模块边界、系统交互、集成方式 - 哪些能力共用，哪些能力专属 完成该层追问后： - 生成或更新“应用架构图” XML 代码块 - 回写应用架构说明文档 - 视需要修正主图中应用层容器内的渠道、系统、模块、外部系统和系统边界 ### 5. Probe the Data Layer 围绕“什么数据被创建、流转、消费和治理”追问： - 核心数据域与主实体 - 数据来源、所有者、消费者 - 主数据、交易数据、分析数据之间的关系 - 数据质量、安全、权限、留存与生命周期 完成该层追问后： - 生成或更新“数据架构图” XML 代码块 - 回写数据架构说明文档 - 视需要修正主图中数据层容器内的数据域、主实体、流向、所有权和治理约束 ### 6. Probe the Technology Layer 围绕“技术如何支撑应用与非功能要求”追问： - 部署形态、运行环境、云或本地 - 接口与集成、中间件、消息、同步异步 - 存储、算力、AI 或算法、可观测性 - 安全、合规、性能、容灾、扩展性 完成该层追问后： - 生成或更新“技术架构图” XML 代码块 - 回写技术架构说明文档 - 视需要修正主图中技术层容器内的运行平台、集成方式、中间件、安全与观测能力 ### 7. Map and Validate 完成初步信息收集后，强制做四类校验： - 每个核心业务能力是否至少有一个应用承接 - 每个核心应用是否读写明确的数据对象 - 每个关键技术组件是否服务于具体应用或质量属性 - 是否存在孤立元素、重复模块、缺失依赖 必要时回到上一个层次继续追问。 ### 8. Validate with External Authority 当以下任一条件成立时，追加外部权威资料校验： - 需要说明某个行业的通行做法、监管要求、合规约束 - 需要判断竞品或标杆产品的能力边界 - 需要确认技术选型、接口规范、标准协议、云服务限制 - 需要给出市场规模、行业趋势、成熟度判断 - 需要把“应该如何设计”建立在“现实世界已经如何运作”之上 执行顺序： 1. 先列出待验证主张，不超过 5 条 2. 为每条主张匹配至少 1 个一手来源 3. 如主张影响重大，再补 1 个独立权威来源交叉验证 4. 记录来源名称、日期、链接、支持的结论、仍未解决的不确定性 5. 用证据修正 4A 图中的假设、能力边界或技术约束 最低门槛： - 一般主张：至少 1 条一手来源 - 关键架构判断：至少 2 条独立来源，其中 1 条必须是一手来源 - 高风险领域：优先只使用官方、监管、标准组织或正式披露文件 ### 9. Produce the Deliverable 默认输出以下内容： 1. 背景与建模边界 2. 关键假设与待确认项 3. 主图 XML 代码块 4. 业务架构图 XML 代码块 5. 应用架构图 XML 代码块 6. 数据架构图 XML 代码块 7. 技术架构图 XML 代码块 8. 四层说明文档 9. 4A 映射矩阵 10. 外部资料校验记录 11. 风险、缺口与下一步建议 ## Question Strategy 优先使用高杠杆问题。选择下一问时，按以下顺序判断： 1. 哪个不确定性会导致整张图重画 2. 哪个不确定性会影响最多层 3. 哪个问题用户最容易回答 4. 是否可以用二选一或三选一降低答题成本 可用的提问句式： - “如果这个产品只能优先服务一类核心用户，最优先的是谁？” - “这项业务能力目前是由一个系统承接，还是由多个系统协同完成？” - “这份关键数据最早在哪里产生，谁对它的准确性负责？” - “这里最先会卡住的是性能、合规，还是跨系统集成？” 不要把问题堆成问卷。保持对话节奏。 ## Deliverable Standard 默认使用 1 张主图、4 张分层图和 3 类文档。先输出主图，再按追问进度补齐四张分图和说明。 draw.io XML 输出要求： - 每张图单独输出一个 `xml` fenced code block - 代码块内容必须是可直接导入 draw.io 的完整 XML，而不是伪代码 - 每张图都要包含 `mxfile > diagram > mxGraphModel > root` 的基本结构 - `root` 下至少包含 `mxCell id="0"` 和 `mxCell id="1" parent="0"` - 所有节点与连线都必须提供明确的 id、parent、style 和 geometry - 图名称固定为：`主图`、`业务架构图`、`应用架构图`、`数据架构图`、`技术架构图` - 如果信息尚不完整，也要输出可导入的初稿 XML，并在文档中标记假设 - 除非用户显式要求，不再以 Mermaid 作为默认图格式 - 主图必须采用 4 层容器式布局，不得用单行节点串联来冒充 4A 主图 - 业务架构图应以角色、场景、能力域、业务规则、KPI 等业务对象为主，不应画成纯操作流程 - 应用架构图应以渠道、应用、服务、外部系统、接口边界为主，不应画成页面点击路径 - 数据架构图应以数据域、实体、来源、消费者、流转与治理为主，不应画成单次数据处理流水线 - 技术架构图应以运行环境、集成、中间件、基础设施、安全、可观测性为主，不应画成部署脚本或调用时序 详细定义、问题库与检查清单见 [references/4a-framework.md](references/4a-framework.md)。 详细输出骨架见 [references/deliverable-template.md](references/deliverable-template.md)。 外部权威资料校验规则见 [references/authority-validation.md](references/authority-validation.md)。 4A 分层图设计规范见 [references/layered-architecture-spec.md](references/layered-architecture-spec.md)。 draw.io XML 结构约束见 [references/drawio-xml-template.md](references/drawio-xml-template.md)。 ## Failure Modes 遇到以下情况，不要直接硬画： - 用户只给了功能列表，没有目标和边界 - 把组织架构、系统架构、流程架构混在一起 - 只描述“要上 AI”，但没有业务触发点和数据闭环 - 把技术选型当成 4A 的起点 - 把阶段路线图、审批链或操作步骤图当成 4A 分层架构图 此时先回到边界、目标用户和核心场景。 ## Final Response Style 交付时保持结构清晰、可复用： - 先给结论，再给图，再给解释 - 先给主图，再给分图，再给文档 - 明确区分“已确认”“假设”“待确认” - 明确区分“外部证据支持”和“基于经验的建议” - 如果信息仍不完整，给出可讨论初稿，而不是空白模板 - 对不确定项给出建议选项，而不是只说“信息不足”