很多工程师学架构，注意力天然落在技术上：用什么框架、怎么分层、怎么拆服务、怎么设计表、怎么画架构图。这些当然重要，但它们回答的只是"系统怎么做"，而架构师还得回答一个更前置的问题——这个系统为什么要做，它服务什么业务目标，未来又为什么会变。

理解这件事，可以先看一个金字塔：

商业目标 / \ 业务模式 业务价值 / \ / \ 业务流程 业务规则 指标数据 产品能力 \ \ / / 领域模型和系统边界 | 技术架构

• 顶层是"为什么"：系统最终为了服务某个商业目标——赚钱、降本、提效、控风险、合规、提升体验。
• 中层是"业务如何运转"：谁参与、怎么协作、有哪些流程、哪些规则不能错、哪些指标判断结果、哪些数据会沉淀。
• 底层是"系统如何支撑"：产品能力、领域模型、系统边界、技术架构。

小白架构师最容易犯的错，是从金字塔底部往上想：先定技术架构，再划系统模块，最后补一段业务解释。正确的顺序恰好相反——先问业务为什么存在，再看它如何运转，再抽象领域对象和规则，最后才设计系统边界和技术架构。

这就引出全文唯一要记住的题眼：

业务决定系统边界，系统边界决定架构形态，架构形态决定技术取舍。

下面我把这条链路拆成七层：商业 → 业务 → 产品 → 领域 → 数据 → 系统 → 架构。为了不停留在抽象，我用同一个 ChatBI 问题贯穿全部七层：

业务提出：希望 ChatBI 能回答用户问的"上个月销售额为什么下降"。

小白工程师的第一反应是：让大模型生成 SQL，查出销售额，再让模型总结原因。
架构师的做法，是让这个问题穿过七层，看它到底需要一套什么样的系统。

先纠正一个误区：懂业务不是背术语

正式进入七层之前，先破一个误解。很多人以为"懂业务"是记住行业黑话、听得懂产品经理说什么、需求来了能快速实现。这些只是表层。

架构师真正需要的，是看懂需求背后的结构。比如业务说"我要一个销售分析看板"，初级理解是"做个页面，展示销售额、订单数、趋势图"。架构师视角要继续往下问：谁看？看完做什么决策？销售额什么口径？哪些数据有权限限制？数据延迟多久可接受？后续会不会扩展到自助问数？

懂业务，是能从"需求描述"穿透到"业务结构"。这正是接下来七层要训练的能力——也是为什么不懂业务的架构师容易做出"技术上很完整、业务上没价值"的系统。

第一层：商业——这个系统为什么值得做

商业关注的是：企业如何创造价值、如何赚钱、如何降本、如何在竞争中活下去。不是每个系统都直接产生收入，但大多数企业软件最终都间接服务某个商业目标：增收、降本、提效、控风险、合规、提升体验。

架构师不需要像老板一样研究商业模式，但至少要问一句：这个系统做不好，业务会损失什么；做好了，业务会获得什么。

回到我们的 ChatBI 问题——它的商业价值不是"自然语言转 SQL"这个技术动作，而是：降低业务人员取数门槛、减少分析师重复取数、提升经营分析效率、让管理者更快发现异常。用户问"销售额为什么下降"，本质不是想要一个数字，而是想诊断经营异常、辅助决策。

技术能力只有连到这个目标上，才有业务意义。这一层定下了系统"为什么存在"，也就定下了它该往哪个方向演进。

第二层：业务——这件事现实中是怎么运转的

业务关注的是：企业如何组织人、流程、规则和资源，为客户提供服务。可以把它理解成现实世界里的一套工作方法——业务没有软件也能跑，只是慢、贵、不透明。

理解业务时，别一上来就想系统页面，先问：谁参与？各自负责什么？他们之间交接什么？哪些规则不能违反？最常见的异常是什么？出了问题谁担责？

我们的 ChatBI 问题里，"销售额下降"这件事在现实中牵涉到不同角色，他们要的答案根本不同：

管理层：是否影响整体目标 区域负责人：哪个区域拖了后腿 运营人员：哪个渠道、活动、品类异常 分析师：口径和数据质量是否可信

同一个问题，因为提问角色不同，背后要支撑的决策也不同（调整投放、优化活动、排查渠道、下钻分析……）。业务这一层告诉我们：系统不能只给一个标准答案，它要能感知"谁在问"。这个判断，后面会直接变成权限和角色的系统边界。

第三层：产品——软件该把哪部分工作固化下来

产品关注的是：软件如何帮业务更高效、更低成本、更稳定地完成工作。产品不是业务本身，而是业务的工具——它把业务里的一部分工作自动化、标准化、可追踪。

所以理解产品要问：它替代了哪些人工动作？沉淀了哪些数据？降低了哪些错误？增加了哪些控制能力？这里有个常见陷阱：业务有时想要一个复杂功能，其实只是因为线下流程没理清。架构师若直接实现，系统只会越来越乱；更好的做法是先帮业务澄清"真实流程是什么、哪些必须系统化、哪些规则还在探索"。

对我们的 ChatBI 来说，产品要固化的不是"聊天框"，而是把"问数—澄清—校验—回答—追溯"这条链路标准化。哪些环节交给模型、哪些必须由系统兜底，正是产品设计的经济性取舍——不是功能越多越好，而是在不破坏业务规则的前提下，用最低成本达成目标。

第四层：领域——抽象出稳定的核心对象

领域是业务理解和架构设计之间最关键的一层。它关注：在某个业务范围内，核心对象、规则、状态和行为是什么。

如果只看功能清单，你得到的是一堆散乱模块（新增订单、修改订单、查询订单、订单导出……）；如果理解业务，你会看到更稳定的对象和关系。ChatBI 场景表面是"用户问、系统答"，深入看，核心对象是：

业务问题 提问角色 指标 维度 筛选条件 时间范围 指标口径 权限主体 数据源 SQL 查询结果 解释文本 审计记录

领域建模要回答三件事：最重要的对象是什么、对象之间什么关系、状态如何变化。订单不是一条简单记录，它有"已创建→已支付→已发货→已签收→已完成/已取消/已退款"的状态流转，每次跳转背后都是业务规则和责任转移。

对我们的问题而言，最该被稳定下来的对象是"指标"和"口径"——因为"销售额"这个词，下一层就会暴露它的全部复杂性。这些对象稳定了，架构才有稳定的边界。

第五层：数据——口径不清，回答得再流畅也是错的

数据关注的是：业务动作产生了什么数据，数据如何被计算、解释、使用和治理。对 AI / Data / ChatBI 方向，这一层尤其致命。

架构师不能只知道有哪些表，还要知道：这个指标怎么算、服务什么决策、从哪来、何时更新、谁能看、质量是否可信、不同部门口径是否一致。

我们的问题在这一层彻底显形——"销售额"根本不是一个数字，而是一组待确认的口径：

下单金额 / 支付金额 / 发货金额 / 确认收货金额 是否扣除退款 / 是否含税 / 是否包含取消订单 "上个月"按自然月，还是按业务周期

而"为什么下降"还要能拆解：

销售额 = 订单数 × 客单价 订单数 = 访问人数 × 转化率 维度：时间 / 区域 / 渠道 / 品类 / 门店 / 新老客 / 活动

如果口径不清楚，ChatBI 回答得再流畅，也可能是一个错误答案。所以系统在这一层的正确行为，不是硬给一个看似确定的结论，而是该澄清时澄清、该提示时提示。AI 时代的数据系统，不只是把数据查出来，而是让数据被可信地理解和消费。

第六层：系统——边界按业务责任划，不按技术兴趣划

系统关注的是：哪些业务能力由哪些系统承载，系统之间如何协作。同一个业务流程往往横跨多个系统（订单、库存、支付、财务、数仓、BI、ChatBI、权限、审计）。

架构师要分清：每个系统负责什么、边界在哪、谁是事实来源、谁只做展示分析、谁出问题影响最大。系统边界不是按技术兴趣划的，而是按业务责任、数据归属、变化频率和质量要求划的。

这正是前几层判断的落点。我们的 ChatBI 问题，在系统层会立刻撞上两条边界：

• 第五层暴露的"口径风险"决定了——指标口径不能交给模型临时猜，必须来自语义层 / 指标治理系统。
• 第二层暴露的"谁在问"决定了——权限不能靠模型自觉遵守，必须由权限系统和 SQL 安全校验兜底（区域负责人只能看自己区域、销售个人数据要脱敏）。

你看，业务理解就是这样一层层压到系统边界上的。

第七层：架构——把业务语言翻译成架构语言

架构关注的是：为支撑当前业务和未来变化，系统该如何分层、分模块、分边界，并在成本、风险、性能、扩展性之间取舍。业务理解最终必须落到这里——能不能把业务问题翻译成架构设计，是"听懂需求"和"具备架构能力"的分水岭。

把前六层对我们这个问题的判断收拢，"上个月销售额为什么下降"背后需要的系统能力是：

意图识别 → 指标/维度语义层 → 时间表达解析 → 口径澄清 → 权限校验 → SQL 生成与安全拦截 → 查询执行 → 结果解释 → 异常归因 → 审计追溯 → 评估集回归

一个看似简单的问法，背后不是"接个大模型"就完了，而是一整套业务可信问数架构。更一般地，业务理解到架构的翻译有一张固定对照表，它是全文的落点：

如果你能把一个业务问题填进这张表，业务理解就真正转化成了架构能力。

回到题眼

走完七层再回看，那个金字塔其实就是一句话：业务决定系统边界，系统边界决定架构形态，架构形态决定技术取舍。

我们用"上个月销售额为什么下降"这一个问题做了完整演示——它从一个商业诊断目标出发，经过角色差异、产品取舍、领域对象、口径风险、系统边界，最终落成一套可信问数架构。这就是架构师理解业务，和普通实现需求之间的区别：不是把技术方案包装成业务语言，而是从业务本质出发，推导出合理的系统形态。

附录：把它变成日常动作

理解业务不能空学，要拿真实需求来练。下面是一套可以长期重复的最小动作。

遇到任何需求，先用九行翻译它：

需求原话 / 提问角色 / 业务目标 / 决策动作 核心对象 / 指标和数据 / 规则和约束 / 系统能力 / 风险点

每周画一条业务链路：参与角色 → 业务动作 → 业务凭证 → 系统参与 → 数据沉淀 → 指标产出 → 决策动作。

每周拆一棵指标树：指标定义 → 计算口径 → 上游数据 → 可拆维度 → 常见误解 → 权限/质量风险。

最后，用十个问题自测你到底理解到哪一层：

1. 能否一句话说清这个业务为什么存在？ 2. 能否说清谁是用户、谁是客户、谁承担成本？ 3. 能否画出业务主流程？ 4. 能否说出核心业务对象？ 5. 能否说出关键规则和异常？ 6. 能否说出核心指标和口径？ 7. 能否说出这个需求服务什么决策？ 8. 能否判断需求变化影响哪一层？ 9. 能否把业务问题翻译成系统能力？ 10. 能否说清技术方案的收益、成本和风险？

只能答到第 3 题，说明你刚听懂需求；答到第 6 题，说明你开始理解业务；答到第 10 题，说明你正在把业务理解变成架构能力。写得漂不漂亮不重要，关键是长期练同一套动作。