【架构实践（1）】架构师如何正确理解业务

这篇文章可以先用一个金字塔来理解：

text 复制代码

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

金字塔最上层是"为什么"。一个系统之所以存在，最终是为了服务商业目标或组织目标，例如赚钱、降本、提效、控风险、合规、提升体验、提高管理透明度。

中间层是"业务如何运转"。包括谁参与业务、他们怎么协作、有哪些核心流程、哪些规则不能错、哪些指标用来判断结果、哪些数据会沉淀下来。

底层是"系统如何支撑"。也就是产品能力、领域模型、数据模型、系统边界、模块划分、接口设计、权限、安全、性能、可用性和演进路线。

小白架构师最容易犯的错误，是从金字塔底部开始思考：

text 复制代码

先想技术架构
-> 再想系统模块
-> 再补业务解释

正确的思考顺序应该反过来：

text 复制代码

先问业务为什么存在
-> 再看业务如何运转
-> 再抽象领域对象和规则
-> 再设计系统边界和技术架构

这就是架构师理解业务的核心：不是把技术方案包装成业务语言，而是从业务本质出发，推导出合理的系统形态。

整篇文章后面的内容，都是围绕这个金字塔展开：

顶层：理解商业目标，知道系统为什么值得做。
中层：理解业务流程、业务规则、业务数据，知道系统要支撑什么。
底层：理解产品、领域、系统和架构，知道技术应该怎么设计。

读这篇文章时，可以始终记住一句话：

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

很多工程师刚开始学习架构时，会自然地把注意力放在技术上：

用什么框架。
怎么分层。
怎么拆服务。
怎么设计表。
怎么保证性能和稳定性。
怎么画架构图。

这些当然重要，但它们还不是架构能力的全部。真正的架构师不能只回答"系统怎么做"，还要回答：

这个系统为什么要做？它服务什么业务目标？它改变了谁的工作方式？它降低了什么成本？它控制了什么风险？它未来为什么会变化？

如果不理解业务，架构设计很容易变成"技术上看起来很完整，但业务上不一定有价值"。这篇文章的目标不是让你立刻成为业务专家，而是先建立一个整体认识：架构师应该如何正确理解业务。

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

很多人一听"懂业务"，会以为是：

记住很多行业名词。
熟悉业务部门的黑话。
产品经理说什么都能听懂。
业务提什么需求都能快速实现。

这些只是表层。

架构师真正需要的业务理解，是看懂业务背后的结构：

text 复制代码

商业目标
-> 业务模式
-> 业务流程
-> 业务规则
-> 业务数据
-> 产品能力
-> 系统架构

也就是说，业务理解不是"听懂别人说什么"，而是能进一步判断：

这个需求背后的真实目标是什么？
用户为什么要这样做？
这个动作会产生什么业务结果？
哪些规则是必须遵守的？
哪些数据是决策依据？
哪些变化会影响系统边界？
技术方案的复杂度是否值得？

小白架构师最容易犯的错误，是把业务理解停留在"需求描述"层面。

例如业务说：

text 复制代码

我要一个销售分析看板。

初级理解是：

text 复制代码

做一个页面，展示销售额、订单数、趋势图。

架构师视角要继续往下问：

text 复制代码

谁看这个看板？
他看完要做什么决策？
销售额的口径是什么？
按哪些维度拆？
哪些数据有权限限制？
数据延迟多久可以接受？
看板错误会造成什么影响？
后续是否会扩展到 ChatBI 自助问数？

这才是"理解业务"。

二、架构师为什么必须理解业务

架构师不是单纯的高级开发。高级开发主要把需求实现好，架构师还要对系统长期形态负责。

系统长期形态不是凭空来的，它来自业务长期变化。

如果不了解业务，至少会出现五类问题。

1. 分不清什么需求重要

业务需求看起来都很急，但不是所有需求都同等重要。

有些需求影响收入，有些影响成本，有些影响效率，有些影响合规，有些只是体验优化。架构师要能区分：

text 复制代码

这个需求是核心业务能力，还是边缘辅助能力？
是长期平台能力，还是一次性临时功能？
是必须进入主链路，还是可以用运营手段解决？

如果分不清，就容易把临时需求做成复杂系统，也可能把核心能力做得很随意。

2. 分不清变化来自哪里

工程师经常抱怨"需求老变"。但架构师要进一步判断需求为什么变。

需求变化大致可以分成几层：

text 复制代码

交互变化：页面、按钮、展示方式变了。
规则变化：计算规则、审批规则、风控规则变了。
流程变化：谁先做、谁后做、谁确认变了。
对象变化：系统里要管理的核心业务对象变了。
业务模式变化：企业服务客户和赚钱的方式变了。

越上层的变化，技术影响越小。越底层的变化，架构影响越大。

例如修改一个按钮文案，通常只是交互变化。修改 GMV 的计算口径，是规则变化。把原来的"人工审批"改成"系统自动决策"，就是流程和权责变化。把一个财务系统硬改成社交系统，可能已经是业务定位变化，原架构未必适合继续承载。

架构师理解业务，是为了判断变化对系统的真实影响。

3. 做不出稳定的领域模型

领域模型不是从数据库表里凭空长出来的，而是从业务对象、业务动作和业务规则里抽象出来的。

如果你只看功能清单，很容易得到一堆散乱模块：

text 复制代码

新增订单
修改订单
查询订单
订单列表
订单导出
订单审核

如果你理解业务，就会看到更稳定的对象和关系：

text 复制代码

客户
订单
商品
价格
库存
支付
履约
退款
结算
发票

在 ChatBI 场景中也是一样。表面看是"用户问问题，系统回答"。深入看，核心对象包括：

text 复制代码

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

这些对象稳定下来，架构才有稳定边界。

4. 无法做技术取舍

架构设计本质上是取舍，不是堆能力。

要不要微服务？要不要引入规则引擎？要不要做配置化？要不要做语义层？要不要异步化？要不要强一致？要不要实时？

这些问题不能只从技术偏好出发，要回到业务判断：

业务是否真的需要实时？
规则是否经常变化？
用户规模是否已经需要拆服务？
错误成本有多高？
数据延迟会不会影响决策？
当前阶段是验证业务，还是规模化运营？
做通用平台的收益是否超过维护成本？

不理解业务，架构师只能说"这个方案技术上更高级"。理解业务后，才能说"这个方案在当前业务阶段更划算"。

5. 很难和业务、产品、上级对齐

架构师经常需要推动方案评审、技术改造、资源投入和长期治理。如果只讲技术，对方不一定能理解为什么要投入。

例如你想建设 ChatBI SQL 安全校验。

纯技术表达是：

text 复制代码

我们需要做 SQL AST 解析、权限校验、慢查询拦截和危险语句识别。

业务表达是：

text 复制代码

ChatBI 让业务用户可以自助问数，但自然语言生成 SQL 存在越权查询、错误口径、慢查询拖垮集群等风险。SQL 安全校验可以降低错误回答和高风险查询的概率，让 ChatBI 从 demo 能力变成可生产使用的能力。

这两种说法不是谁替代谁，而是面向不同听众。架构师要能在技术语言和业务语言之间切换。

三、正确理解业务的主线：从商业到系统

理解业务可以按一条主线来走：

text 复制代码

商业
-> 业务
-> 产品
-> 领域
-> 数据
-> 系统
-> 架构

这条链路非常重要。小白架构师可以先不求深入，但一定要知道每一层在问什么。

四、第一层：理解商业

商业关注的是：

企业如何创造价值，如何赚钱，如何降低成本，如何在竞争中活下去。

不一定每个系统都直接产生收入，但大多数企业软件最终都间接服务商业目标。

常见商业目标包括：

增加收入。
降低成本。
提高效率。
降低风险。
提升客户体验。
支撑合规。
提高管理透明度。
提升组织协同效率。

架构师不需要像老板一样研究商业模式，但至少要问：

text 复制代码

这个系统最终服务什么商业目标？
是为了赚钱、降本、提效、控风险，还是合规？
如果这个系统做不好，业务会损失什么？
如果这个系统做好了，业务会获得什么？

例如 ChatBI 的商业价值不是"自然语言转 SQL"，而是：

text 复制代码

降低业务人员取数门槛。
减少数据分析师重复取数。
提升经营分析效率。
让管理者更快发现异常。
让企业数据资产更容易被消费。

技术能力只有连到这些价值上，才有业务意义。

五、第二层：理解业务

业务关注的是：

企业如何组织人、流程、规则和资源，为客户提供服务。

可以把业务理解成一套现实世界里的工作方法。

例如一个食材配送业务，现实中可能是：

text 复制代码

餐厅老板提出采购需求
-> 客户经理确认订单
-> 仓库备货
-> 配送员送货
-> 餐厅签收
-> 财务对账
-> 周期结算

这里面有客户、订单、货物、仓库、配送、签收、对账、结算等对象，也有不同角色之间的责任转移。

理解业务时，不要一上来就想系统页面，而要先问：

text 复制代码

谁参与这个业务？
他们各自负责什么？
他们之间交接什么东西？
哪些凭证能证明事情发生过？
哪些规则不能违反？
哪些异常最常见？
出了问题谁承担责任？

这些问题比"页面怎么做"更接近业务本质。

六、第三层：理解产品

产品关注的是：

软件如何帮助业务更高效、更低成本、更稳定地完成工作。

业务可以没有软件也能跑，只是慢、贵、不透明、不稳定。软件的价值，是把业务中的一部分工作自动化、标准化、可追踪、可复制。

所以理解产品时，要问：

text 复制代码

这个产品替代了哪些人工动作？
减少了哪些沟通成本？
沉淀了哪些数据？
提升了哪些效率？
降低了哪些错误？
增加了哪些控制能力？

产品不是业务本身，而是业务的工具。这个认识很重要。

有时候业务想要一个复杂功能，其实只是因为线下流程不清楚。架构师如果直接实现，系统会越来越乱。更好的做法是先帮业务澄清：

text 复制代码

真实流程是什么？
哪些动作必须系统化？
哪些动作可以运营处理？
哪些规则需要固化？
哪些规则还在探索？

产品设计要讲经济性。不是功能越多越好，也不是流程越短越好，而是在不破坏业务规则和责任边界的前提下，用尽量低的成本完成业务目标。

七、第四层：理解领域

领域关注的是：

在某个业务范围内，核心对象、规则、状态和行为是什么。

这是业务理解和架构设计之间最关键的一层。

例如电商领域中，常见核心对象是：

text 复制代码

用户
商品
订单
支付
库存
优惠
物流
退款
结算

数据平台和 ChatBI 领域中，核心对象可能是：

text 复制代码

数据源
数据表
字段
指标
维度
口径
权限
查询
血缘
质量规则
业务问题
回答结果

领域理解要解决三个问题：

text 复制代码

这个业务里最重要的对象是什么？
这些对象之间有什么关系？
对象的状态如何变化？

例如订单不是一条简单记录，它有状态：

text 复制代码

已创建
已支付
已发货
已签收
已完成
已取消
已退款

状态变化背后是业务规则和责任变化。架构师如果看不到这些，只把订单当成一张表，就很难设计出可演进的系统。

八、第五层：理解数据

数据关注的是：

业务动作产生了什么数据，数据如何被计算、解释、使用和治理。

对你当前的 AI/Data/ChatBI 方向来说，数据理解尤其重要。

架构师不能只知道有哪些表，还要知道：

text 复制代码

这个字段是什么意思？
这个指标怎么算？
这个指标服务什么决策？
这个数据从哪里来？
数据什么时候更新？
谁可以看？
质量是否可信？
不同部门口径是否一致？
错误数据会造成什么影响？

例如"销售额"这个指标，可能有多种口径：

text 复制代码

下单金额
支付金额
发货金额
确认收货金额
扣除退款后的金额
含税金额
不含税金额

如果口径不清楚，ChatBI 回答得再流畅，也可能是错误答案。

所以数据平台架构师和 ChatBI 架构师理解业务时，要特别关注：

指标口径。
维度体系。
数据质量。
权限控制。
血缘关系。
审计追踪。
结果解释。
业务可验证性。

AI 时代的数据系统，不只是把数据查出来，还要让数据被可信地理解和消费。

九、第六层：理解系统

系统关注的是：

哪些业务能力由哪些系统承载，系统之间如何协作。

同一个业务流程，可能涉及多个系统：

text 复制代码

前台应用
订单系统
库存系统
支付系统
财务系统
数据仓库
BI 系统
ChatBI 系统
权限系统
审计系统

架构师要理解：

text 复制代码

每个系统负责什么？
边界在哪里？
数据从哪里来，到哪里去？
哪个系统是事实来源？
哪个系统只做展示或分析？
哪个系统可以异步？
哪个系统必须强一致？
哪个系统出问题影响最大？

系统边界不是按技术兴趣划分的，而是按业务责任、数据归属、变化频率和质量要求划分的。

例如在 ChatBI 场景中，模型可以生成答案，但指标口径不能完全交给模型临时猜。口径应该来自语义层或指标治理系统。权限不能靠模型自觉遵守，而要由权限系统和 SQL 安全校验兜底。

这就是业务理解对系统边界的影响。

十、第七层：理解架构

架构关注的是：

为了支撑当前业务和未来变化，系统应该如何分层、分模块、分边界，并在成本、风险、性能、扩展性之间做取舍。

业务理解最终要落到架构判断上。

你要能把业务语言翻译成架构语言：

业务理解	架构映射
谁能做什么	权限模型
业务怎么流转	工作流 / 状态机
核心业务对象	领域模型 / 数据模型
规则经常变化	规则配置 / 规则引擎
指标口径必须一致	语义层 / 指标平台
数据不能越权	权限校验 / SQL 拦截
错误影响决策	审计 / 可追溯 / 质量提示
需求仍在探索	快速验证 / 低成本试错
业务已经稳定	平台化 / 标准化 / 自动化

这张表很重要。它说明业务理解不是停留在沟通层，而是要进入设计层。

如果不能把业务问题翻译成架构设计，说明业务理解还没有真正转化为架构能力。

十一、小白架构师理解业务的 8 个固定问题

以后遇到任何需求，先问 8 个问题。

1. 这个需求服务谁？

区分用户角色：

老板 / 管理层。
业务负责人。
运营人员。
产品经理。
数据分析师。
开发和运维人员。
外部客户。

不同角色的目标不同，对系统的要求也不同。

2. 他要完成什么业务动作？

不要只听他说"我要看一个页面""我要导出一个报表"。继续问：

text 复制代码

看完之后要做什么？
导出之后要给谁？
这个动作影响什么决策？

3. 这个动作背后的业务目标是什么？

常见目标包括：

提升收入。
降低成本。
提高效率。
控制风险。
满足合规。
提升体验。
支撑管理。

4. 这个业务现在是怎么做的？

系统化之前，业务通常已经存在。问清楚现状：

text 复制代码

现在用 Excel 吗？
现在靠人工沟通吗？
现在谁审批？
现在谁确认？
现在哪里最慢？
现在哪里最容易出错？

现状流程是领域建模的重要来源。

5. 核心业务对象是什么？

找名词：

text 复制代码

订单
客户
商品
合同
账单
指标
维度
数据表
审批单
任务
规则

这些名词不一定都要变成数据库表，但它们通常是理解系统边界的线索。

6. 核心规则和约束是什么？

问：

text 复制代码

什么情况下允许？
什么情况下不允许？
谁能操作？
谁能查看？
错了能不能撤回？
是否要留痕？
历史数据怎么处理？

很多系统复杂度都藏在规则和异常里。

7. 如何判断做成了？

验收不能只写"功能可用"。要问：

text 复制代码

效率提升多少？
错误率降低多少？
响应时间要求多少？
数据延迟允许多久？
用户满意度如何衡量？
是否有业务指标验证？

8. 最大风险是什么？

风险包括：

数据错误。
权限越权。
性能拖垮。
规则遗漏。
用户不使用。
流程不闭环。
历史数据迁移失败。
和现有系统边界冲突。

架构师要提前看到风险，而不是上线后才补救。

十二、用 ChatBI 举一个完整例子

假设业务提出：

text 复制代码

希望 ChatBI 支持用户问"上个月销售额为什么下降"。

小白工程师可能会想：

text 复制代码

让大模型生成 SQL，查出销售额，再让模型总结原因。

架构师要拆成一条完整链路。

1. 业务目标

用户不是单纯想知道数字，而是想诊断经营异常。

text 复制代码

目标：发现销售额下降原因，辅助业务调整策略。

2. 提问角色

不同角色需要不同答案：

text 复制代码

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

3. 决策动作

可能的决策包括：

text 复制代码

调整投放。
优化活动。
排查渠道。
调整品类策略。
关注异常区域。
继续下钻分析。

4. 指标和维度

销售额需要拆：

text 复制代码

销售额 = 订单数 * 客单价
订单数 = 访问人数 * 转化率

常见维度：

text 复制代码

时间
区域
渠道
品类
门店
新老客
活动
销售团队

5. 口径风险

必须确认：

text 复制代码

销售额是下单金额还是支付金额？
是否扣除退款？
是否含税？
是否包含取消订单？
上个月按自然月还是业务周期？

如果口径不清楚，系统应该澄清或提示，而不是直接给出看似确定的答案。

6. 权限风险

区域负责人是否只能看自己区域？运营人员是否能看全公司？销售个人数据是否需要脱敏？

这决定了 ChatBI 不能只依赖模型回答，还要有权限控制、SQL 校验和审计。

7. 架构映射

这个需求背后需要的系统能力包括：

text 复制代码

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

你会发现，一个简单问法背后不是"接个大模型"就完了，而是一整套业务可信问数架构。

这就是架构师理解业务和普通实现需求的区别。

十三、判断自己是否真正理解了业务

可以用这 10 个问题自测：

text 复制代码

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

如果只能回答前 3 个，说明你刚刚听懂需求。

如果能回答到第 6 个，说明你开始理解业务。

如果能回答到第 10 个，说明你正在把业务理解转化为架构能力。

十四、日常训练方法

不要脱离工作空学业务。最有效的方法，是把每个真实需求都拿来练。

每天 10 分钟：需求翻译练习

遇到一个需求，就写：

text 复制代码

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

每周 1 次：画业务链路

选择一个业务场景，画：

text 复制代码

参与角色
-> 业务动作
-> 业务凭证
-> 系统参与
-> 数据沉淀
-> 指标产出
-> 决策动作

每周 1 次：拆指标树

选择一个指标，拆：

text 复制代码

指标定义
计算口径
上游数据
可拆维度
驱动指标
反向指标
常见误解
权限风险
质量风险

每周 1 次：写业务到架构映射

选择一个需求，写：

text 复制代码

业务问题：
业务价值：
核心流程：
核心对象：
关键规则：
系统边界：
架构取舍：
验收指标：
风险控制：

写得不漂亮没关系。关键是长期练同一套动作。