在当今快速发展的互联网行业中，系统架构设计是确保产品成功的关键因素之一。但你是否曾经对着复杂的系统架构图感到困惑，不知道如何下手？
本文写给已负责或即将独立负责系统，为系统架构设计苦恼的产品人&曾经的自己：
系统架构系列目录：
我所在的大部门内部是乐于分享的，此前能听到很多产品对自己负责的业务&系统进行分享，有幸看过了很多系统架构图，有意思的是，不同产品经理负责分享时的系统架构图都不太一样，举2个明显差异化的例子：
催收系统架构图：
认证中心架构图
可以看到上述2个系统架构图有明显差异：
从2021年到现在，期间有过几次困惑：系统架构图是非标的吗，为什么每个人的系统架构图都，各有千秋呢？随着主导各类系统从0到1或系统重构的项目经历不断丰富，对于系统架构的理解才有了自己的答案；
在互联网中，公司商业模式的主营业务流往往需要多个系统支撑串联，而支撑业务的系统都有自己的侧重，不同侧重类型的系统，其架构表达形式自然有差异；
从众多系统全盘看，系统可以分为3类，每一类都有各自的特点；
名词解释：核心功能，代指系统中提供的核心能力；以各类系统的核心能力举例
系统架构是产品经理梳理出来，面向人员（其他相关产品经理、开发人员、测试人员），让其能够清晰的明白系统的定位和能力以及系统边界（其与上下游外部系统的关系）；
通过明确业务系统架构的价值，反向推断一个系统架构图中应当具备的元素和内容，这样系统架构需要做什么，就很明确了：
而系统功能点的来源，是将线下的业务人员具体行动的事件，转化到线上系统进行支持体现；同理，系统之间的信息流转，本质也是业务之间的往来体现；因此要想无遗漏的梳理功能点，同时明确系统内外部信息流的前提，是对业务进行全链路的梳理；
为此，我将整个系统架构设计分4步：
看面抽线（理解业务模式→抽出业务主线）→挖点抽象（清点角色事件→挖掘提炼功能点）→归类（有序模块化功能）→串流向（串联内外部系统信息流）
看面：是指我们从全盘看整个业务的运转（商业）模式：涉及哪些外部角色，怎么赚钱的？这样可以让我们迅速对业务有一个全盘的了解。
以法催业务模式举例：
在了解业务模式后，整个业务团队与外部角色的联系就非常清晰了，这样也避免我们视野的局限。
抽线：是指从业务团队内部看他们处理的核心事务，梳理出业务运转的主线流程，以法催的全链路业务流程举例：
当业务主线流程梳理清楚后，后续的挖点才不会遗漏相关角色处理的事件；
挖点：是指我们基于主线流程，按照阶段性拆分，清点每个阶段分别有哪些角色参与，分别都在什么规则下做了什么事件，最终基于事件挖掘出业务人员所需的功能点；
当按照阶段、角色、规则、事件表格梳理完成后，每个角色在指定规则下需要执行的事件，业务侧需要系统承载的功能点就很清晰了。
抽象：是指从众多的事物中抽取出共同的、本质性的特征，而舍弃其非本质的特征的过程。
抽象的价值在于避免系统中出现很多同质化的功能，这样系统就越轻量，系统建设的总人力投入成本越少；
举例：
这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个公用且具备可拓展性的功能点；
后续若业务方在提类似信息管控策略，那么此前我们开发的单个前置条件或执行事件，即可直接复用，这样系统功能点就精炼了许多；
归类：是指将全盘功能点按照一定规则进行模块化分类；
归类的价值：模块在系统架构中展示会更直观，尤其是在一个复杂庞大的业务系统架构图，这时信息越精炼，架构图越具有可读性；
但归类模块时，功能点的随意组合会让架构图里的模块显得很混乱：以法催举例
上述模块中，第一眼看到很多功能点，这些功能点服务的角色并不相同，之间也都没有什么关联，看着有些混乱；
而对功能点抽象分类，就可以清晰的表达功能点为哪些角色提供了哪些能力：例如案件分配/调整等是同一类事件，代表案件流转；外呼/短信/律师函等是同一类事件，代表案件作业；通过事件分类进行模块如下：
以事件抽象进行分类，进行模块化展示，成型后的架构图对于业务的体现将一目了然！
串流向：是指通过连线，表达上下游系统与业务系统之间的信息流向；
一个完整的系统架构，除了内部阶段模块化体现业务流向，还需要展现展示外部系统与内部系统的信息流向，这样系统的全貌才算完整了；
信息流向的梳理可以从业务的开端进行梳理，判断每个业务环节与外部系统有无交互，所需要的数据是否外部系统提供：以法催举例：
最终，内外部信息流，结合全量业务事件抽象归类后的功能模块，即可完整的体现系统的架构，还是以法催举例：
务系统不同于工具型，服务型系统，其服务范围群体虽然专一，但业务深度却对一条线从头到尾进行了全链路的覆盖，要想全面有效的完成系统架构的设计，离不开对业务链路的深入理解；
所以，系统架构的设计思路是：
理解业务流：
梳理信息流：
工具系统&服务系统的架构设计由于篇幅过长，考虑到2类系统设计思路基本相同，后续会按照单独成篇梳理。
作者：橙言，互金风控产品经理；公众号：橙言（ChenYan_515）
本文由 @橙言 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。