在当今快速发展的互联网行业中，系统架构设计是确保产品成功的关键因素之一。但你是否曾经对着复杂的系统架构图感到困惑，不知道如何下手？

本文写给已负责或即将独立负责系统，为系统架构设计苦恼的产品人&曾经的自己：

系统架构系列目录：

• 三大系统架构设计-业务系统篇（本篇）
• 三大系统架构设计-工具&服务系统篇（下篇）

一、困惑

我所在的大部门内部是乐于分享的，此前能听到很多产品对自己负责的业务&系统进行分享，有幸看过了很多系统架构图，有意思的是，不同产品经理负责分享时的系统架构图都不太一样，举2个明显差异化的例子：

催收系统架构图：

认证中心架构图

可以看到上述2个系统架构图有明显差异：

1. 前者按照业务主线横向拆分阶段，模块化来体现系统架构；
2. 后者按照关联业务&业务应用&服务组件纵向分层，模块化来体现系统架构；

从2021年到现在，期间有过几次困惑：系统架构图是非标的吗，为什么每个人的系统架构图都，各有千秋呢？随着主导各类系统从0到1或系统重构的项目经历不断丰富，对于系统架构的理解才有了自己的答案；

在互联网中，公司商业模式的主营业务流往往需要多个系统支撑串联，而支撑业务的系统都有自己的侧重，不同侧重类型的系统，其架构表达形式自然有差异；

从众多系统全盘看，系统可以分为3类，每一类都有各自的特点；

二、系统分类&特点

名词解释：核心功能，代指系统中提供的核心能力；以各类系统的核心能力举例

• 决策引擎核心提供：策略配置&信息决策的能力；
• 贷后催收系统核心提供：提供逾期案件准备&案件分配&辅助催收员案件作业的能力；
• 呼叫中心核心提供：呼出、呼入有关的服务；

三、业务系统的架构设计思路

系统架构是产品经理梳理出来，面向人员（其他相关产品经理、开发人员、测试人员），让其能够清晰的明白系统的定位和能力以及系统边界（其与上下游外部系统的关系）；

通过明确业务系统架构的价值，反向推断一个系统架构图中应当具备的元素和内容，这样系统架构需要做什么，就很明确了：

1. 系统定位和能力→本质是功能点的具象化来体现对业务的支持；
2. 系统边界→系统与上下游外部系统的关联关系→确定系统之间的信息流转；

而系统功能点的来源，是将线下的业务人员具体行动的事件，转化到线上系统进行支持体现；同理，系统之间的信息流转，本质也是业务之间的往来体现；因此要想无遗漏的梳理功能点，同时明确系统内外部信息流的前提，是对业务进行全链路的梳理；

为此，我将整个系统架构设计分4步：

看面抽线（理解业务模式→抽出业务主线）→挖点抽象（清点角色事件→挖掘提炼功能点）→归类（有序模块化功能）→串流向（串联内外部系统信息流）

1. 看面→抽线

看面：是指我们从全盘看整个业务的运转（商业）模式：涉及哪些外部角色，怎么赚钱的？这样可以让我们迅速对业务有一个全盘的了解。

以法催业务模式举例：

在了解业务模式后，整个业务团队与外部角色的联系就非常清晰了，这样也避免我们视野的局限。

抽线：是指从业务团队内部看他们处理的核心事务，梳理出业务运转的主线流程，以法催的全链路业务流程举例：

当业务主线流程梳理清楚后，后续的挖点才不会遗漏相关角色处理的事件；

2. 挖点→抽象

挖点：是指我们基于主线流程，按照阶段性拆分，清点每个阶段分别有哪些角色参与，分别都在什么规则下做了什么事件，最终基于事件挖掘出业务人员所需的功能点；

当按照阶段、角色、规则、事件表格梳理完成后，每个角色在指定规则下需要执行的事件，业务侧需要系统承载的功能点就很清晰了。

抽象：是指从众多的事物中抽取出共同的、本质性的特征，而舍弃其非本质的特征的过程。

抽象的价值在于避免系统中出现很多同质化的功能，这样系统就越轻量，系统建设的总人力投入成本越少；

举例：

• A前置条件，执行M事件，假设开发“A条件”需投入1人日，开发执行事件需投入1人日；
• B前置条件，执行M事件，假设“B条件”需投入1人日，开发执行事件需投入1人日；

这2个事件最终实现为2个功能点，总计投入4人日，其中执行M事件被重复开发了1次，产生1人日的人力浪费；

但当我们将A&B前置抽象为一类条件，将这2类事件合并为1个事件：（A或B前置条件）执行M事件，其中开发执行M事件仅需投入1人日，总计投入3人日，即可完成1人日的人力节省。

投入的对比可以直观的体现出抽象精炼功能点的必要性，那么具体应该怎么抽象呢？

我们从前置条件，执行事件组合来看

• 相同的前置条件下，执行了相同的事件；
• 相同的前置条件下，执行了不同的事件；
• 不同的前置条件下，执行了相同的事件；
• 不同的前置条件下，执行了不同的事件；

当出现N个不同前置条件时，判断将N个具体条件是否可以归为同1类（不那么具体）的前置条件，判断依据是这些不具体的前置条件必须具体共性的特征；执行事件同理；由N归1的过程既是抽象；

举例：我之前负责贷后催收针对业务需求抽象的实际案例：

需求中的前置条件，是否未来还会出现其他指定条件，例如逾期天数不超过3天，或者指定渠道&逾期金额不超过3000，是否可以抽象为“可配置”的条件组？这样允许用户组合不同条件自由配置需要执行哪些事件，最终形成1个灵活可配置的信息管控策略功能；

整个思考过程中，先将前置条件or执行事件拓宽，再从拓宽的多项抽取出共同特征–在将前置条件从N个抽象为1类，这样整个需求经过抽象后设计成了1个公用且具备可拓展性的功能点；

后续若业务方在提类似信息管控策略，那么此前我们开发的单个前置条件或执行事件，即可直接复用，这样系统功能点就精炼了许多；

3. 归类

归类：是指将全盘功能点按照一定规则进行模块化分类；

归类的价值：模块在系统架构中展示会更直观，尤其是在一个复杂庞大的业务系统架构图，这时信息越精炼，架构图越具有可读性；

但归类模块时，功能点的随意组合会让架构图里的模块显得很混乱：以法催举例

上述模块中，第一眼看到很多功能点，这些功能点服务的角色并不相同，之间也都没有什么关联，看着有些混乱；

而对功能点抽象分类，就可以清晰的表达功能点为哪些角色提供了哪些能力：例如案件分配/调整等是同一类事件，代表案件流转；外呼/短信/律师函等是同一类事件，代表案件作业；通过事件分类进行模块如下：

以事件抽象进行分类，进行模块化展示，成型后的架构图对于业务的体现将一目了然！

4. 串流向

串流向：是指通过连线，表达上下游系统与业务系统之间的信息流向；

一个完整的系统架构，除了内部阶段模块化体现业务流向，还需要展现展示外部系统与内部系统的信息流向，这样系统的全貌才算完整了；

信息流向的梳理可以从业务的开端进行梳理，判断每个业务环节与外部系统有无交互，所需要的数据是否外部系统提供：以法催举例：

5. 成型的业务系统架构图

最终，内外部信息流，结合全量业务事件抽象归类后的功能模块，即可完整的体现系统的架构，还是以法催举例：

四、总结

务系统不同于工具型，服务型系统，其服务范围群体虽然专一，但业务深度却对一条线从头到尾进行了全链路的覆盖，要想全面有效的完成系统架构的设计，离不开对业务链路的深入理解；

所以，系统架构的设计思路是：

理解业务流：

1. 看面抽线：理解业务模式→抽出业务主线；
2. 挖点抽象：清点角色事件→挖掘提炼功能点；
3. 归类：有序模块化功能；

梳理信息流：

1. 串信息流向：串联内外部系统信息流；

工具系统&服务系统的架构设计由于篇幅过长，考虑到2类系统设计思路基本相同，后续会按照单独成篇梳理。

拓展阅读：

• 风控系列1.信贷法催业务模式与系统架构
• 风控系列2.信贷电催业务模式与系统架构
• 风控系列5. 信贷风控到底在干什么？