夜雨聆风学习资料网

ARTICLE · 1110205

软件解决方案设计-十大领域知识图谱

发布时间：2026-10-01 17:51:50 最近访问：2026-10-01 17:51:51
软件解决方案设计-十大领域知识图谱
刚开始做 BA 时，我们很容易把“解决方案”理解成一种很具体的东西。
用户说需要审批，我们就画审批流程。
用户说客户太多找不到，我们就加一个搜索框。
用户说想看数据，我们就做一张报表。
用户说不同系统之间要同步，我们就开一个接口。
这些都没错。
但做的项目越来越多以后，会慢慢发现：真正的软件解决方案，从来不是某一个页面、某一个功能、某一个接口。
它更像一栋建筑。
用户最后看到的页面只是装修。
页面背后还有：
• 业务流程。
• 业务规则。
• 数据模型。
• 状态和工作流。
• 系统集成。
• 权限和安全。
• 报表分析。
• 自动化。
• 性能、可靠性等非功能约束。
一个方案如果只把其中一层设计好，往往只能做到“局部可用”。
真正成熟的解决方案，必须回答：
业务如何运行，系统管理什么事实，用户如何操作，不同模块如何协作，哪些错误必须被阻止，以及这套系统能不能稳定地长期运行。
我把这些内容整理成了上面这张“软件解决方案设计十大领域知识图谱”。
先说明一点：
这十类不是某个行业组织发布的官方十分类法。
它是一张面向 ERP、企业系统、商业分析师和项目经理的实用地图。每一个领域背后都有成熟的软件工程、商业分析、数据、交互设计或架构知识体系，只是为了工作中方便使用，我把它们重新组织到了一张图上。
这张图真正有价值的地方不是“记住十个名词”。
而是以后再遇到一个需求时，你能够意识到：
我现在看到的，只是解决方案的一部分。还有哪些维度我没有检查？

一、先理解一件事：Solution Design 不是画页面

如果业务提出：
我们需要一个新的客户收款功能。
一个刚开始做 BA 的人，很容易马上想到页面：
• 客户字段放哪里。
• 收款金额怎么输入。
• 保存按钮叫什么。
• 是否需要一个查询页面。
但一个 Senior BA 听到同样一句话，脑子里通常会同时展开很多问题。
业务流程上：
谁收到银行信息？谁确认客户？谁完成对账？
业务规则上：
超额收款怎么办？不同币种能不能直接匹配？
数据上：
Receipt、Invoice、Customer、Allocation 之间是什么关系？
状态上：
收款从新建到确认到结清，中间有哪些状态？
集成上：
银行数据从哪里来？凭证发送到哪里？
权限上：
谁能创建，谁能确认，谁能撤销？
交互上：
客户很多的时候怎么快速找到正确客户？
报表上：
财务怎么知道还有多少未结？
自动化上：
能不能根据金额和客户自动推荐匹配？
非功能上：
一天几万笔交易时还能不能跑得动？
这就是 Senior BA 和“记录功能需求”的区别之一。
Senior BA 看到的不是一个页面，而是一整套相互连接的系统能力。

二、第一类：业务流程方案——业务到底应该怎么走

这是最上层，也最容易被低估的一层。
业务流程方案回答的是：
这件业务从开始到结束，应该怎样运行？
图里把它拆成四部分：
• 流程建模与分析。
• 流程优化与自动化。
• 端到端流程设计。
• 流程绩效与监控。

1．流程建模与分析

最基础的问题是：
现在到底怎么做？
假设业务说：
客户付款以后，我们要做对账。
不能只记录“需要对账”。
你至少需要知道：
客户付款
→ 银行收到款项
→ 财务识别客户
→ 查找对应正式应收
→ 处理手续费或汇兑差异
→ 对账
→ 更新余额
这里需要分析：
• 谁负责每一步。
• 输入是什么。
• 输出是什么。
• 哪些步骤发生在系统里。
• 哪些发生在邮件、表格或人工沟通里。
流程建模不是为了画一张漂亮流程图，而是把业务实际如何运行变成可讨论的事实。

2．流程优化与自动化

知道现状以后，第二个问题才是：
哪些地方应该改变？
比如原来用户收到银行流水后，要：
复制客户名称
→ 打开 ERP
→ 搜客户
→ 找未结发票
→ 人工核对金额
→ 再确认
可能其中有些步骤可以自动完成。
但“自动化”不是默认目标。
有些流程慢，是因为系统操作多。
有些流程慢，是因为业务规则本身不清楚。
不要把一个混乱流程直接自动化。自动化只会让混乱跑得更快。

3．端到端流程设计

这是 Senior BA 特别需要培养的意识。
很多需求局部来看都合理：
销售希望快速开单。
财务希望严格控制。
仓库希望尽快出货。
如果每个模块分别优化，最后可能整个流程反而更差。
所以需要看：
从最开始的业务事件，到最终业务结果，整条链路是否成立？
例如：
订单
→ 出货
→ 发票
→ 收款
→ 对账
→ 凭证
任何一段断掉，都不能算完整。
局部功能完成，不等于端到端业务闭环。

4．流程绩效与监控

流程上线以后，还要知道：
• 平均处理时间。
• 哪一步经常卡住。
• 哪类异常最多。
• 哪些任务长期未完成。
这就是流程绩效。
如果一个流程没有任何监控，几年以后很可能再次变成：
大家都知道它不好用，但没人说得清哪里不好。

三、第二类：功能与业务规则——系统到底允许什么，不允许什么

很多初级 BA 比较擅长写功能：
系统需要支持创建客户。
系统需要支持修改订单。
但真正复杂的企业系统，难点通常不是 Function，而是 Rule。
图里包括：
• 功能需求定义。
• 业务规则建模。
• 决策与计算逻辑。
• 规则可配置性。

1．功能需求定义

功能回答：
系统能做什么？
例如：
• 创建收款。
• 分配预收。
• 撤销对账。
• 查询余额。
这是最容易理解的一层。

2．业务规则建模

规则回答：
在什么条件下可以做？
例如：
• 已关闭期间不能新增凭证。
• 不同公司的应收不能互相对账。
• 同一笔预收累计使用金额不能超过余额。
• 已报废对象不能再进入维修。
这部分才是企业系统真正复杂的地方。
页面数量可能只有十张，业务规则却可能有几百条。

3．决策与计算逻辑

一些规则不是简单 Yes / No，而是计算。
比如：
含税金额怎么算。
折扣先算还是税先算。
汇兑差异用哪个汇率。
哪个责任部门应该接收任务。
这类内容应该被明确写成决策逻辑，而不是埋在程序里。

4．规则可配置性

再成熟一点，会继续问：
这个规则以后会不会变化？
例如审批金额：
现在可能是：
超过 100,000 需要主管批准。
如果这个数字每年都会调整，就不应该写死在代码里。
应该考虑：
是否做成配置。
这就是 Solution Design 的一个典型升级：
不是只设计“今天怎么运行”，还要判断“未来变化时应该改代码，还是改配置”。

四、第三类：数据方案——系统到底在记录什么事实

这是我认为 BA 最容易低估、但长期最重要的领域之一。
图里包括：
• 概念、逻辑、物理数据模型。
• 数据流与数据集成。
• 数据质量与主数据管理。
• 数据安全与合规。

1．概念、逻辑、物理数据模型

BA 最需要理解的是前两层。
概念层先回答：
业务世界里有哪些重要对象？
例如：
Customer
Invoice
Receipt
Allocation
然后看关系：
一个 Customer 有多张 Invoice。
一笔 Receipt 可以分配给多张 Invoice。
一张 Invoice 也可能接受多笔 Receipt。
这已经决定了系统底层很多东西。
如果真实业务是多对多，你却只设计一个 Invoice No. 字段，复杂度不会消失。
它只会被迫进入：
• 备注。
• Excel。
• 人工记忆。

2．数据流与数据集成

还要知道数据从哪里来，到哪里去。
例如 Customer：
CRM 创建
→ ERP 使用
→ 财务报表引用
→ 数据仓库分析
这时必须知道：
谁才是客户资料的 Source of Truth？
否则几个系统都会觉得自己可以修改客户名称。

3．数据质量与主数据管理

企业系统很多问题，表面上看是程序问题，实际是数据问题。
例如：
同一个客户存在三个名字。
一个机器有两个编号。
供应商地址没有标准。
币种代码混乱。
所以数据方案必须考虑：
• 唯一性。
• 完整性。
• 一致性。
• 有效性。
• 数据所有权。

4．数据安全与合规

数据不是所有人都应该看到。
例如薪资、银行账户、身份证、客户隐私。
所以数据设计从来不能只问：
放哪个字段。
还需要问：
谁可以看到？
保存多久？
是否需要脱敏？

五、第四类：工作流与状态——业务对象如何发生变化

你最近做状态机时，其实已经深入进入了这一领域。
图里包括：
• 流程引擎与审批流。
• 状态机设计。
• 异常与回退机制。
• 任务分配与协作。

1．流程引擎与审批流

例如：
申请人
→ 部门主管
→ 财务
→ 总经理
这属于 Workflow。
重点包括：
• 谁审批。
• 什么条件进入下一层。
• 拒绝以后去哪里。
• 是否允许代理。
• 是否允许加签。

2．状态机设计

状态机回答：
一个对象如何从 A 状态走到 B 状态？
成熟的状态规则至少要考虑：
• 状态定义。
• 允许来源。
• 触发动作。
• Dependency。
• 操作权限。
• Exit Rule。
• 异常规则。
所以：
状态不是一个字段，而是一整套业务控制。

3．异常与回退机制

正常流程永远最好画。
真正困难的是：
• 审批错了怎么办？
• 已完成能否撤销？
• 接口失败怎么办？
• 用户误操作怎么办？
一个只设计 Happy Path 的状态机，通常上线以后很快就会出现大量人工修数据。

4．任务分配与协作

系统还需要知道：
• 谁应该处理。
• 如何知道自己有任务。
• 超时以后怎么办。
• 人离职以后任务怎么办。
Workflow 不是单纯状态变化，也包含人的协作。

六、第五类：集成方案——系统之间如何交换事实

现代企业里几乎没有真正孤立的软件。
图里的集成领域包括：
• 接口设计。
• 数据映射与转换。
• 集成模式与架构。
• 错误处理与重试机制。

1．接口设计

最常见的可能是：
API
消息
文件
初级 BA 容易只关心：
传哪些字段？
Senior BA 还会问：
• 谁调用谁？
• 实时还是批量？
• 一次传一条还是一批？
• 谁确认成功？

2．数据映射与转换

系统 A 叫：
Customer Code
系统 B 叫：
Partner ID
不仅要映射字段名称，还要考虑：
• 格式。
• 枚举值。
• 单位。
• 币种。
• 日期。
• 空值。
字段 Mapping 实际上是一种业务语义 Mapping。

3．集成模式与架构

再往上一层，会思考：
两个系统应该直接连接，还是通过中间层？
谁是主系统？
同步还是异步？
BA 不一定需要设计技术架构，但需要理解这些选择会影响业务体验。

4．错误处理与重试机制

这是非常容易被漏掉的。
例如：
ERP 已经成功生成凭证。
接口返回超时。
发送方以为失败，再发送一次。
结果生成两张凭证。
这就是为什么会需要：
• 重试。
• 去重。
• 幂等。
• 错误队列。
接口设计真正难的不是成功的时候怎么传，而是失败以后系统怎么保持正确。

七、第六类：权限与安全控制——谁可以做什么

图里包括：
• 用户与角色管理。
• 权限模型与访问控制。
• 数据安全与隐私保护。
• 审计与合规要求。

1．用户与角色管理

首先要知道：
谁是谁。
例如：
销售。
财务。
主管。
管理员。

2．权限模型与访问控制

然后继续：
每个角色能做什么？
但 ERP 的权限通常比 RBAC 更复杂。
比如一个财务用户：
可以看香港公司的单。
不能看越南公司的单。
可以创建。
不能批准自己创建的单。
所以权限往往是：
Role + Company + Data Scope + Status + Action
共同决定。

3．数据安全与隐私保护

“能打开页面”不代表可以看到所有字段。
例如：
普通员工可以看供应商名称。
但未必可以看银行账户。

4．审计与合规要求

系统还必须回答：
• 谁改过。
• 原来是什么。
• 改成什么。
• 什么时候改。
• 为什么改。
很多企业系统真正重要的不是“不允许修改”。
而是：
允许修改，但必须留下证据。

八、第七类：交互与用户体验——用户到底如何和系统合作

图里包括：
• 界面布局与导航。
• 表单与输入设计。
• 搜索与自动完成。
• 可用性与可访问性。

1．界面布局与导航

用户到底怎么找到功能？
是：
菜单？
Tab？
快捷入口？
Dashboard？
页面设计的第一步不是颜色，而是：
信息和操作怎么组织。

2．表单与输入设计

企业系统大量时间都花在输入。
所以需要考虑：
• 默认值。
• 自动带值。
• 条件必填。
• 日期选择。
• 下拉。
• 单选。
• 多选。
• Lookup。
好的 Form Design 能显著降低错误。

3．搜索与自动完成

搜索可以继续拆成：
搜索触发：
• 点击搜索。
• 回车搜索。
• 输入即搜索。
匹配方式：
• 精确匹配。
• 前缀匹配。
• 包含匹配。
• 模糊匹配。
输入辅助：
• 自动完成。
• 联想搜索。
• 历史搜索。
结果缩小：
• Filter。
• Faceted Search。
• Sort。
比如业务说：
客户很多，我总找不到。
真正成熟的 Solution 可能是：
输入两个字符以后开始查询，同时匹配客户编号和客户名称，只返回当前公司有效客户，并以下拉列表显示编号、名称和地区，用户必须从合法结果中选择。
一句话里面其实已经包含：
• 输入即搜索。
• 多字段匹配。
• 权限/业务过滤。
• 自动完成。
• Selection Control。
这就是 Solution Pattern 的价值。

4．可用性与可访问性

系统是不是“能用”，和“好用”不是一回事。
例如：
错误提示：
Error 20037
技术上是提示了。
用户完全不知道怎么办。
好的提示应该告诉用户：
当前客户已经存在未完成申请，请先完成或取消原申请。
好的交互设计，本质上是在减少用户理解系统规则的成本。

九、第八类：报表与分析——不是展示数据，而是支持判断

图里包括：
• 报表需求与设计。
• 数据可视化。
• 自助分析与多维分析。
• 数据导出与共享。

1．报表需求与设计

用户说：
我要一个 Report。
不能马上问列什么字段。
应该先问：
你看这个报表是为了做什么决定？
因为：
管理层。
执行人员。
财务。
审计。
需要的报表完全不同。

2．数据可视化

什么时候用表格？
什么时候用趋势图？
什么时候用异常颜色？
图表不是为了“高级”。
而是要帮助人更快识别模式。

3．自助分析与多维分析

例如管理人员希望自己切换：
公司。
客户。
月份。
产品。
地区。
这时就可能需要 Pivot、OLAP、自助分析。

4．数据导出与共享

不要觉得 Export Excel 很低级。
企业系统里它经常很重要。
关键是理解：
为什么导出？
如果用户导出只是为了重新算一遍系统已经应该提供的数字，那可能不是“需要 Excel”，而是系统能力缺失。

十、第九类：自动化与智能化——哪些事情不应该继续让人做

图里包括：
• 流程自动化。
• 智能推荐与预测。
• 规则引擎与决策支持。
• 人工智能与机器学习。

1．流程自动化

最基础的自动化其实不需要 AI。
例如：
自动带值。
自动分派。
自动通知。
自动生成编号。
自动创建下一步任务。
很多企业系统自动化的最大收益，其实来自这些普通能力。

2．智能推荐与预测

再往前一步：
系统不只是执行规则，而是帮助用户判断。
例如：
推荐最可能匹配的收款。
预测订单延期。
推荐库存补货。

3．规则引擎与决策支持

如果规则很多，而且经常变化，可以考虑把判断逻辑从程序代码中抽出来。
例如：
风险评分。
审批路径。
价格规则。

4．AI / 机器学习应用

再进一步才是：
OCR。
文本分类。
大模型。
Agent。
但这里 Senior BA 需要特别克制：
不要因为 AI 能做，就默认 AI 应该做。
要先问：
• 这个任务频率高吗？
• 输入稳定吗？
• 有没有足够数据？
• 错误成本高吗？
• 人能不能复核？
• AI 比规则真正好在哪里？

十一、第十类：非功能需求与技术约束——系统不只是“能不能”，还有“能不能长期稳定地”

图里包括：
• 性能与响应时间。
• 可用性与可靠性。
• 可扩展性与维护性。
• 技术选型与架构约束。

1．性能与响应时间

比如：
客户有 500 条时，下拉没问题。
客户变成 100,000 条呢？
这时候就可能需要：
服务端搜索。
分页。
索引。
缓存。
所以你今天讨论的“输入即搜索”，背后其实可能已经涉及非功能需求。

2．可用性与可靠性

系统一天允许停多久？
接口失败以后能不能恢复？
关键财务操作能不能丢？
这些不会出现在用户第一句需求里，但却决定系统是否可信。

3．可扩展性与维护性

今天只有香港公司。
明年加入三个国家怎么办？
今天只有一种审批。
明年新增五种怎么办？
好的方案需要考虑未来合理范围内的变化。

4．技术选型与架构约束

例如企业已经规定：
必须使用某个平台。
只能部署内网。
必须使用统一认证。
必须调用既有主数据平台。
这些都属于 Solution Constraint。
Solution Design 不是在真空中寻找“最好方案”，而是在真实约束下寻找最合适方案。

十二、这十个领域不是十条独立的路，而是一张网

这一点特别重要。
不要学完以后认为：
一个需求属于数据，就不属于交互。
真实需求往往同时跨多个领域。
举一个我们前面讨论过的简单例子：
客户很多，用户很难快速找到正确客户。
表面上这是一个搜索问题。
实际上至少涉及：
交互设计
输入即搜索、自动完成、结果展示。
数据方案
Customer No. 和 Customer Name 哪些字段可以搜索？
业务规则
什么叫“有效客户”？
权限
用户能看到哪些公司的客户？
非功能
十万客户时响应时间是多少？
集成
客户资料是不是来自另一个主数据系统？
所以：
一个很小的搜索框，都可能同时跨越六个 Solution Domain。
这也是为什么经验丰富的 BA 在讨论一个很小需求时，经常会突然问：
这些客户从哪个系统来？
用户可能觉得：
我不是只让你改一个搜索框吗？
但 BA 知道：
如果 Data Ownership 没搞清楚，搜索框只是问题的最表层。

十三、Junior BA 和 Senior BA 的一个重要差别：能不能看到“遗漏的领域”

Junior BA 经常是跟着需求走。
用户说：
我要增加一个状态。
于是开始设计状态。
Senior BA 则会自然继续展开：
状态变化是否影响权限？
是否触发通知？
报表如何统计？
接口出去以后传哪个状态？
历史状态是否需要保留？
能不能撤销？
异常以后怎么恢复？
不是 Senior BA 天生想得更多。
而是他的脑子里已经有一张地图。
当一个区域亮起来时，他会自然检查旁边几个相关区域。
这张“十大领域知识图谱”最大的作用，其实就是这样：
把经验丰富的人脑子里隐性的检查项，逐渐变成显性的框架。

十四、初级 BA 可以怎样真正使用这张图

不要背。
每次新需求开始时，拿它做一次 Solution Scan。
例如业务说：
我们希望新增一个供应商申请流程。
可以逐个问。
业务流程
申请从谁开始，到谁结束？
功能与规则
什么供应商允许申请？重复供应商怎么判断？
数据
Supplier、Application、Company 怎么关联？
工作流状态
Draft、Submitted、Approved、Rejected 怎么走？
集成
审批通过以后是否同步 ERP？
权限
谁可以申请？谁可以看银行资料？
交互
表单怎么填？供应商如何搜索？
报表
采购部需要看到哪些 Pending Application？
自动化
是否自动查重、自动通知？
非功能
供应商上传附件大小限制是多少？敏感资料如何保护？
这十个问题走一遍，你就会发现：
很多所谓“需求遗漏”，其实不是用户没有告诉你，而是你没有从那个领域去问。

十五、但千万不要把这张图变成机械 Checklist

框架最大的风险，是让人开始机械化。
每个需求都一定要写十个章节吗？
不需要。
一个简单字段修改，可能只有：
功能规则 + 数据 + 交互
三个领域值得深入。
一个财务系统迁移，可能十个全部涉及。
框架不是为了增加文档。
而是为了帮助判断：
这次问题的复杂度主要在哪里？哪些领域可以快速确认，哪些必须深入分析？
好的 BA 不是把所有事情都分析得很复杂。
而是：
复杂问题不漏关键，简单问题不制造复杂。

十六、从 BA 到 Solution BA，真正增加的是什么

很多人以为从 BA 往上走，就是：
懂更多业务。
会更多工具。
写更完整文档。
这些当然重要。
但还有一层更关键的变化：
开始拥有自己的 Solution Pattern Library。
用户说：
数据不好找。
你想到 Search & Lookup Pattern。
用户说：
同一件事一直重复处理。
你想到 Idempotency / Duplicate Prevention。
用户说：
一个订单要分给多人。
你想到 Allocation。
用户说：
完成以后状态不知道回哪里。
你想到 State Machine / Exit Rule。
用户说：
权限越来越乱。
你想到 Role + Data Scope + Action Control。
经验到了这个阶段以后，就不再只是：
我以前做过类似项目。
而是：
我知道这属于哪类问题，这类问题通常有哪些成熟解法，各自适用于什么条件。
这就是经验真正开始复利的地方。

十七、最后：先诊断，再开药，但你必须知道药柜里有什么

我很喜欢用医学来理解这件事。
好的医生不会听到“胸痛”，立刻决定做手术。
他会先：
症状
→ 检查
→ 诊断
→ 比较治疗方案
→ 治疗
BA 也是一样：
业务抱怨
→ 定义问题
→ 找根因
→ 定义能力
→ 比较方案
→ 设计 Solution
所以我们一直强调：
不要过早 Solutionize。
但这句话很容易被误解成：
BA 不需要懂 Solution。
其实正好相反。
BA 不应该过早开药，但必须知道药柜里有什么。
否则问题即使分析得再准确，最后能够提出的方案仍然非常有限。
这张十大领域知识图谱对我最大的意义，也正在这里。
它让我开始把过去做过的流程、状态、权限、数据、接口、搜索、报表和自动化重新放回一张地图。
以后再碰到一个新的概念，不再只是问：
这个词是什么意思？
而会继续问：
它属于哪个领域？
它解决的是哪一类问题？
它的上层是什么？
它下面还有哪些 Solution Pattern？
什么场景应该使用它？
当知识开始有位置以后，项目经验才不再只是一个个孤立案例。
它们开始逐渐变成一套可以重复调用的软件解决方案能力。

相关学习资料