很多工程师学架构注意力天然落在技术上用什么框架、怎么分层、怎么拆服务、怎么设计表、怎么画架构图。这些当然重要但它们回答的只是系统怎么做而架构师还得回答一个更前置的问题——这个系统为什么要做它服务什么业务目标未来又为什么会变。理解这件事可以先看一个金字塔商业目标 / \ 业务模式 业务价值 / \ / \ 业务流程 业务规则 指标数据 产品能力 \ \ / / 领域模型和系统边界 | 技术架构顶层是为什么系统最终为了服务某个商业目标——赚钱、降本、提效、控风险、合规、提升体验。中层是业务如何运转谁参与、怎么协作、有哪些流程、哪些规则不能错、哪些指标判断结果、哪些数据会沉淀。底层是系统如何支撑产品能力、领域模型、系统边界、技术架构。小白架构师最容易犯的错是从金字塔底部往上想先定技术架构再划系统模块最后补一段业务解释。正确的顺序恰好相反——先问业务为什么存在再看它如何运转再抽象领域对象和规则最后才设计系统边界和技术架构。这就引出全文唯一要记住的题眼业务决定系统边界系统边界决定架构形态架构形态决定技术取舍。下面我把这条链路拆成七层商业 → 业务 → 产品 → 领域 → 数据 → 系统 → 架构。为了不停留在抽象我用同一个 ChatBI 问题贯穿全部七层业务提出希望 ChatBI 能回答用户问的上个月销售额为什么下降。小白工程师的第一反应是让大模型生成 SQL查出销售额再让模型总结原因。架构师的做法是让这个问题穿过七层看它到底需要一套什么样的系统。先纠正一个误区懂业务不是背术语正式进入七层之前先破一个误解。很多人以为懂业务是记住行业黑话、听得懂产品经理说什么、需求来了能快速实现。这些只是表层。架构师真正需要的是看懂需求背后的结构。比如业务说我要一个销售分析看板初级理解是做个页面展示销售额、订单数、趋势图。架构师视角要继续往下问谁看看完做什么决策销售额什么口径哪些数据有权限限制数据延迟多久可接受后续会不会扩展到自助问数懂业务是能从需求描述穿透到业务结构。这正是接下来七层要训练的能力——也是为什么不懂业务的架构师容易做出技术上很完整、业务上没价值的系统。第一层商业——这个系统为什么值得做商业关注的是企业如何创造价值、如何赚钱、如何降本、如何在竞争中活下去。不是每个系统都直接产生收入但大多数企业软件最终都间接服务某个商业目标增收、降本、提效、控风险、合规、提升体验。架构师不需要像老板一样研究商业模式但至少要问一句这个系统做不好业务会损失什么做好了业务会获得什么。回到我们的 ChatBI 问题——它的商业价值不是自然语言转 SQL这个技术动作而是降低业务人员取数门槛、减少分析师重复取数、提升经营分析效率、让管理者更快发现异常。用户问销售额为什么下降本质不是想要一个数字而是想诊断经营异常、辅助决策。技术能力只有连到这个目标上才有业务意义。这一层定下了系统为什么存在也就定下了它该往哪个方向演进。第二层业务——这件事现实中是怎么运转的业务关注的是企业如何组织人、流程、规则和资源为客户提供服务。可以把它理解成现实世界里的一套工作方法——业务没有软件也能跑只是慢、贵、不透明。理解业务时别一上来就想系统页面先问谁参与各自负责什么他们之间交接什么哪些规则不能违反最常见的异常是什么出了问题谁担责我们的 ChatBI 问题里销售额下降这件事在现实中牵涉到不同角色他们要的答案根本不同管理层是否影响整体目标 区域负责人哪个区域拖了后腿 运营人员哪个渠道、活动、品类异常 分析师口径和数据质量是否可信同一个问题因为提问角色不同背后要支撑的决策也不同调整投放、优化活动、排查渠道、下钻分析……。业务这一层告诉我们系统不能只给一个标准答案它要能感知谁在问。这个判断后面会直接变成权限和角色的系统边界。第三层产品——软件该把哪部分工作固化下来产品关注的是软件如何帮业务更高效、更低成本、更稳定地完成工作。产品不是业务本身而是业务的工具——它把业务里的一部分工作自动化、标准化、可追踪。所以理解产品要问它替代了哪些人工动作沉淀了哪些数据降低了哪些错误增加了哪些控制能力这里有个常见陷阱业务有时想要一个复杂功能其实只是因为线下流程没理清。架构师若直接实现系统只会越来越乱更好的做法是先帮业务澄清真实流程是什么、哪些必须系统化、哪些规则还在探索。对我们的 ChatBI 来说产品要固化的不是聊天框而是把问数—澄清—校验—回答—追溯这条链路标准化。哪些环节交给模型、哪些必须由系统兜底正是产品设计的经济性取舍——不是功能越多越好而是在不破坏业务规则的前提下用最低成本达成目标。第四层领域——抽象出稳定的核心对象领域是业务理解和架构设计之间最关键的一层。它关注在某个业务范围内核心对象、规则、状态和行为是什么。如果只看功能清单你得到的是一堆散乱模块新增订单、修改订单、查询订单、订单导出……如果理解业务你会看到更稳定的对象和关系。ChatBI 场景表面是用户问、系统答深入看核心对象是业务问题 提问角色 指标 维度 筛选条件 时间范围 指标口径 权限主体 数据源 SQL 查询结果 解释文本 审计记录领域建模要回答三件事最重要的对象是什么、对象之间什么关系、状态如何变化。订单不是一条简单记录它有已创建→已支付→已发货→已签收→已完成/已取消/已退款的状态流转每次跳转背后都是业务规则和责任转移。对我们的问题而言最该被稳定下来的对象是指标和口径——因为销售额这个词下一层就会暴露它的全部复杂性。这些对象稳定了架构才有稳定的边界。第五层数据——口径不清回答得再流畅也是错的数据关注的是业务动作产生了什么数据数据如何被计算、解释、使用和治理。对 AI / Data / ChatBI 方向这一层尤其致命。架构师不能只知道有哪些表还要知道这个指标怎么算、服务什么决策、从哪来、何时更新、谁能看、质量是否可信、不同部门口径是否一致。我们的问题在这一层彻底显形——销售额根本不是一个数字而是一组待确认的口径下单金额 / 支付金额 / 发货金额 / 确认收货金额 是否扣除退款 / 是否含税 / 是否包含取消订单 上个月按自然月还是按业务周期而为什么下降还要能拆解销售额 订单数 × 客单价 订单数 访问人数 × 转化率 维度时间 / 区域 / 渠道 / 品类 / 门店 / 新老客 / 活动如果口径不清楚ChatBI 回答得再流畅也可能是一个错误答案。所以系统在这一层的正确行为不是硬给一个看似确定的结论而是该澄清时澄清、该提示时提示。AI 时代的数据系统不只是把数据查出来而是让数据被可信地理解和消费。第六层系统——边界按业务责任划不按技术兴趣划系统关注的是哪些业务能力由哪些系统承载系统之间如何协作。同一个业务流程往往横跨多个系统订单、库存、支付、财务、数仓、BI、ChatBI、权限、审计。架构师要分清每个系统负责什么、边界在哪、谁是事实来源、谁只做展示分析、谁出问题影响最大。系统边界不是按技术兴趣划的而是按业务责任、数据归属、变化频率和质量要求划的。这正是前几层判断的落点。我们的 ChatBI 问题在系统层会立刻撞上两条边界第五层暴露的口径风险决定了——指标口径不能交给模型临时猜必须来自语义层 / 指标治理系统。第二层暴露的谁在问决定了——权限不能靠模型自觉遵守必须由权限系统和 SQL 安全校验兜底区域负责人只能看自己区域、销售个人数据要脱敏。你看业务理解就是这样一层层压到系统边界上的。第七层架构——把业务语言翻译成架构语言架构关注的是为支撑当前业务和未来变化系统该如何分层、分模块、分边界并在成本、风险、性能、扩展性之间取舍。业务理解最终必须落到这里——能不能把业务问题翻译成架构设计是听懂需求和具备架构能力的分水岭。把前六层对我们这个问题的判断收拢上个月销售额为什么下降背后需要的系统能力是意图识别 → 指标/维度语义层 → 时间表达解析 → 口径澄清 → 权限校验 → SQL 生成与安全拦截 → 查询执行 → 结果解释 → 异常归因 → 审计追溯 → 评估集回归一个看似简单的问法背后不是接个大模型就完了而是一整套业务可信问数架构。更一般地业务理解到架构的翻译有一张固定对照表它是全文的落点业务理解架构映射谁能做什么权限模型业务怎么流转工作流 / 状态机核心业务对象领域模型 / 数据模型规则经常变化规则配置 / 规则引擎指标口径必须一致语义层 / 指标平台数据不能越权权限校验 / SQL 拦截错误影响决策审计 / 可追溯 / 质量提示需求仍在探索快速验证 / 低成本试错业务已经稳定平台化 / 标准化 / 自动化如果你能把一个业务问题填进这张表业务理解就真正转化成了架构能力。回到题眼走完七层再回看那个金字塔其实就是一句话业务决定系统边界系统边界决定架构形态架构形态决定技术取舍。我们用上个月销售额为什么下降这一个问题做了完整演示——它从一个商业诊断目标出发经过角色差异、产品取舍、领域对象、口径风险、系统边界最终落成一套可信问数架构。这就是架构师理解业务和普通实现需求之间的区别不是把技术方案包装成业务语言而是从业务本质出发推导出合理的系统形态。附录把它变成日常动作理解业务不能空学要拿真实需求来练。下面是一套可以长期重复的最小动作。遇到任何需求先用九行翻译它需求原话 / 提问角色 / 业务目标 / 决策动作 核心对象 / 指标和数据 / 规则和约束 / 系统能力 / 风险点每周画一条业务链路参与角色 → 业务动作 → 业务凭证 → 系统参与 → 数据沉淀 → 指标产出 → 决策动作。每周拆一棵指标树指标定义 → 计算口径 → 上游数据 → 可拆维度 → 常见误解 → 权限/质量风险。最后用十个问题自测你到底理解到哪一层1. 能否一句话说清这个业务为什么存在 2. 能否说清谁是用户、谁是客户、谁承担成本 3. 能否画出业务主流程 4. 能否说出核心业务对象 5. 能否说出关键规则和异常 6. 能否说出核心指标和口径 7. 能否说出这个需求服务什么决策 8. 能否判断需求变化影响哪一层 9. 能否把业务问题翻译成系统能力 10. 能否说清技术方案的收益、成本和风险只能答到第 3 题说明你刚听懂需求答到第 6 题说明你开始理解业务答到第 10 题说明你正在把业务理解变成架构能力。写得漂不漂亮不重要关键是长期练同一套动作。
很多工程师学架构注意力天然落在技术上用什么框架、怎么分层、怎么拆服务、怎么设计表、怎么画架构图。这些当然重要但它们回答的只是系统怎么做而架构师还得回答一个更前置的问题——这个系统为什么要做它服务什么业务目标未来又为什么会变。理解这件事可以先看一个金字塔商业目标 / \ 业务模式 业务价值 / \ / \ 业务流程 业务规则 指标数据 产品能力 \ \ / / 领域模型和系统边界 | 技术架构顶层是为什么系统最终为了服务某个商业目标——赚钱、降本、提效、控风险、合规、提升体验。中层是业务如何运转谁参与、怎么协作、有哪些流程、哪些规则不能错、哪些指标判断结果、哪些数据会沉淀。底层是系统如何支撑产品能力、领域模型、系统边界、技术架构。小白架构师最容易犯的错是从金字塔底部往上想先定技术架构再划系统模块最后补一段业务解释。正确的顺序恰好相反——先问业务为什么存在再看它如何运转再抽象领域对象和规则最后才设计系统边界和技术架构。这就引出全文唯一要记住的题眼业务决定系统边界系统边界决定架构形态架构形态决定技术取舍。下面我把这条链路拆成七层商业 → 业务 → 产品 → 领域 → 数据 → 系统 → 架构。为了不停留在抽象我用同一个 ChatBI 问题贯穿全部七层业务提出希望 ChatBI 能回答用户问的上个月销售额为什么下降。小白工程师的第一反应是让大模型生成 SQL查出销售额再让模型总结原因。架构师的做法是让这个问题穿过七层看它到底需要一套什么样的系统。先纠正一个误区懂业务不是背术语正式进入七层之前先破一个误解。很多人以为懂业务是记住行业黑话、听得懂产品经理说什么、需求来了能快速实现。这些只是表层。架构师真正需要的是看懂需求背后的结构。比如业务说我要一个销售分析看板初级理解是做个页面展示销售额、订单数、趋势图。架构师视角要继续往下问谁看看完做什么决策销售额什么口径哪些数据有权限限制数据延迟多久可接受后续会不会扩展到自助问数懂业务是能从需求描述穿透到业务结构。这正是接下来七层要训练的能力——也是为什么不懂业务的架构师容易做出技术上很完整、业务上没价值的系统。第一层商业——这个系统为什么值得做商业关注的是企业如何创造价值、如何赚钱、如何降本、如何在竞争中活下去。不是每个系统都直接产生收入但大多数企业软件最终都间接服务某个商业目标增收、降本、提效、控风险、合规、提升体验。架构师不需要像老板一样研究商业模式但至少要问一句这个系统做不好业务会损失什么做好了业务会获得什么。回到我们的 ChatBI 问题——它的商业价值不是自然语言转 SQL这个技术动作而是降低业务人员取数门槛、减少分析师重复取数、提升经营分析效率、让管理者更快发现异常。用户问销售额为什么下降本质不是想要一个数字而是想诊断经营异常、辅助决策。技术能力只有连到这个目标上才有业务意义。这一层定下了系统为什么存在也就定下了它该往哪个方向演进。第二层业务——这件事现实中是怎么运转的业务关注的是企业如何组织人、流程、规则和资源为客户提供服务。可以把它理解成现实世界里的一套工作方法——业务没有软件也能跑只是慢、贵、不透明。理解业务时别一上来就想系统页面先问谁参与各自负责什么他们之间交接什么哪些规则不能违反最常见的异常是什么出了问题谁担责我们的 ChatBI 问题里销售额下降这件事在现实中牵涉到不同角色他们要的答案根本不同管理层是否影响整体目标 区域负责人哪个区域拖了后腿 运营人员哪个渠道、活动、品类异常 分析师口径和数据质量是否可信同一个问题因为提问角色不同背后要支撑的决策也不同调整投放、优化活动、排查渠道、下钻分析……。业务这一层告诉我们系统不能只给一个标准答案它要能感知谁在问。这个判断后面会直接变成权限和角色的系统边界。第三层产品——软件该把哪部分工作固化下来产品关注的是软件如何帮业务更高效、更低成本、更稳定地完成工作。产品不是业务本身而是业务的工具——它把业务里的一部分工作自动化、标准化、可追踪。所以理解产品要问它替代了哪些人工动作沉淀了哪些数据降低了哪些错误增加了哪些控制能力这里有个常见陷阱业务有时想要一个复杂功能其实只是因为线下流程没理清。架构师若直接实现系统只会越来越乱更好的做法是先帮业务澄清真实流程是什么、哪些必须系统化、哪些规则还在探索。对我们的 ChatBI 来说产品要固化的不是聊天框而是把问数—澄清—校验—回答—追溯这条链路标准化。哪些环节交给模型、哪些必须由系统兜底正是产品设计的经济性取舍——不是功能越多越好而是在不破坏业务规则的前提下用最低成本达成目标。第四层领域——抽象出稳定的核心对象领域是业务理解和架构设计之间最关键的一层。它关注在某个业务范围内核心对象、规则、状态和行为是什么。如果只看功能清单你得到的是一堆散乱模块新增订单、修改订单、查询订单、订单导出……如果理解业务你会看到更稳定的对象和关系。ChatBI 场景表面是用户问、系统答深入看核心对象是业务问题 提问角色 指标 维度 筛选条件 时间范围 指标口径 权限主体 数据源 SQL 查询结果 解释文本 审计记录领域建模要回答三件事最重要的对象是什么、对象之间什么关系、状态如何变化。订单不是一条简单记录它有已创建→已支付→已发货→已签收→已完成/已取消/已退款的状态流转每次跳转背后都是业务规则和责任转移。对我们的问题而言最该被稳定下来的对象是指标和口径——因为销售额这个词下一层就会暴露它的全部复杂性。这些对象稳定了架构才有稳定的边界。第五层数据——口径不清回答得再流畅也是错的数据关注的是业务动作产生了什么数据数据如何被计算、解释、使用和治理。对 AI / Data / ChatBI 方向这一层尤其致命。架构师不能只知道有哪些表还要知道这个指标怎么算、服务什么决策、从哪来、何时更新、谁能看、质量是否可信、不同部门口径是否一致。我们的问题在这一层彻底显形——销售额根本不是一个数字而是一组待确认的口径下单金额 / 支付金额 / 发货金额 / 确认收货金额 是否扣除退款 / 是否含税 / 是否包含取消订单 上个月按自然月还是按业务周期而为什么下降还要能拆解销售额 订单数 × 客单价 订单数 访问人数 × 转化率 维度时间 / 区域 / 渠道 / 品类 / 门店 / 新老客 / 活动如果口径不清楚ChatBI 回答得再流畅也可能是一个错误答案。所以系统在这一层的正确行为不是硬给一个看似确定的结论而是该澄清时澄清、该提示时提示。AI 时代的数据系统不只是把数据查出来而是让数据被可信地理解和消费。第六层系统——边界按业务责任划不按技术兴趣划系统关注的是哪些业务能力由哪些系统承载系统之间如何协作。同一个业务流程往往横跨多个系统订单、库存、支付、财务、数仓、BI、ChatBI、权限、审计。架构师要分清每个系统负责什么、边界在哪、谁是事实来源、谁只做展示分析、谁出问题影响最大。系统边界不是按技术兴趣划的而是按业务责任、数据归属、变化频率和质量要求划的。这正是前几层判断的落点。我们的 ChatBI 问题在系统层会立刻撞上两条边界第五层暴露的口径风险决定了——指标口径不能交给模型临时猜必须来自语义层 / 指标治理系统。第二层暴露的谁在问决定了——权限不能靠模型自觉遵守必须由权限系统和 SQL 安全校验兜底区域负责人只能看自己区域、销售个人数据要脱敏。你看业务理解就是这样一层层压到系统边界上的。第七层架构——把业务语言翻译成架构语言架构关注的是为支撑当前业务和未来变化系统该如何分层、分模块、分边界并在成本、风险、性能、扩展性之间取舍。业务理解最终必须落到这里——能不能把业务问题翻译成架构设计是听懂需求和具备架构能力的分水岭。把前六层对我们这个问题的判断收拢上个月销售额为什么下降背后需要的系统能力是意图识别 → 指标/维度语义层 → 时间表达解析 → 口径澄清 → 权限校验 → SQL 生成与安全拦截 → 查询执行 → 结果解释 → 异常归因 → 审计追溯 → 评估集回归一个看似简单的问法背后不是接个大模型就完了而是一整套业务可信问数架构。更一般地业务理解到架构的翻译有一张固定对照表它是全文的落点业务理解架构映射谁能做什么权限模型业务怎么流转工作流 / 状态机核心业务对象领域模型 / 数据模型规则经常变化规则配置 / 规则引擎指标口径必须一致语义层 / 指标平台数据不能越权权限校验 / SQL 拦截错误影响决策审计 / 可追溯 / 质量提示需求仍在探索快速验证 / 低成本试错业务已经稳定平台化 / 标准化 / 自动化如果你能把一个业务问题填进这张表业务理解就真正转化成了架构能力。回到题眼走完七层再回看那个金字塔其实就是一句话业务决定系统边界系统边界决定架构形态架构形态决定技术取舍。我们用上个月销售额为什么下降这一个问题做了完整演示——它从一个商业诊断目标出发经过角色差异、产品取舍、领域对象、口径风险、系统边界最终落成一套可信问数架构。这就是架构师理解业务和普通实现需求之间的区别不是把技术方案包装成业务语言而是从业务本质出发推导出合理的系统形态。附录把它变成日常动作理解业务不能空学要拿真实需求来练。下面是一套可以长期重复的最小动作。遇到任何需求先用九行翻译它需求原话 / 提问角色 / 业务目标 / 决策动作 核心对象 / 指标和数据 / 规则和约束 / 系统能力 / 风险点每周画一条业务链路参与角色 → 业务动作 → 业务凭证 → 系统参与 → 数据沉淀 → 指标产出 → 决策动作。每周拆一棵指标树指标定义 → 计算口径 → 上游数据 → 可拆维度 → 常见误解 → 权限/质量风险。最后用十个问题自测你到底理解到哪一层1. 能否一句话说清这个业务为什么存在 2. 能否说清谁是用户、谁是客户、谁承担成本 3. 能否画出业务主流程 4. 能否说出核心业务对象 5. 能否说出关键规则和异常 6. 能否说出核心指标和口径 7. 能否说出这个需求服务什么决策 8. 能否判断需求变化影响哪一层 9. 能否把业务问题翻译成系统能力 10. 能否说清技术方案的收益、成本和风险只能答到第 3 题说明你刚听懂需求答到第 6 题说明你开始理解业务答到第 10 题说明你正在把业务理解变成架构能力。写得漂不漂亮不重要关键是长期练同一套动作。
/YOLO扑克牌检测)
