架构图套路（转）

画了2000张架构图后，我悟出了一个“范式”，本文就唠唠这个范式。不得不说，我的很多图，高层领导们都喜欢！

 

即高端大气上档次，又兼具艺术之美感，最重要的是——企业用了，腰不酸了，腿不疼了，再也不担心产品团队不怎么行了！

有一次跟一个头部机构副总裁聊天，他告诉我，直接把我的账务架构图扔给产研团队：“就按这个做！”——有魄力，有胆识，有眼光！

我的架构设计案例

懂架构不一定是大师，但，大师一定善于架构，善于拨开迷雾，看透全局。俗话说，看清问题很容易，但，看清全局需要的不止是知识，更是方法，也是范式；所以，我们需要一个固定的范式，去解决所有问题，去看清更大的局面！——看大局，解小题！

本文以家政为例，更直观和具体的给大家分享一下我的“宏观架构思维的范式”的底层逻辑

但其方法和思路并不局限于家政行业，而是提供了一个通用范本，换作其他行业同样适用。大家可以将这5步作为模版，将自己所在行业和所做的工作往上套，得出自己的宏观框架

 

1.先洞悉行业，建底座

家政一般指家政服务行业，涵盖月嫂、育儿嫂、保姆、保洁等多项业务。家政服务人员需要上门为客户提供服务，服务周期通常以小时、天、月、年等为单位，并与客户签订服务合同。

• 月嫂：主要负责为新生儿及宝妈提供专业护理服务，服务对象一般为刚出生几个月内的宝宝。
• 育儿嫂：专注于照顾幼儿，服务年龄范围通常为0.5岁至4岁。
• 保姆：提供日常照顾和护理服务，主要服务对象为家中老人，包括照顾生活起居、打扫卫生、做饭等。
• 保洁：主要负责家庭卫生打扫、油烟机清洗、擦玻璃等室内清洁服务。

家政行业的供需关系如下：核心主体是“家政服务人员”，他们直接为客户提供家政服务。而提供家政服务平台的则包括小型家政公司、垂直的大型家政平台以及综合平台中的家政业务模块等。客户群体既有个人客户，也有企业客户，如图1所示。

图1 家政行业供需关系

一个典型的垂直家政平台，通常采用互联网模式，向消费者（包括客户和家政服务人员）提供家政服务信息。其业务模式涵盖平台业务、自营服务、经纪人服务、SaaS技术赋能以及培训服务等多个方面。随着企业的不断发展，将围绕“家政”领域构建一个更大、更完整的服务生态体系，如图2所示。

图2 垂直家政平台的业务架构

2.再抽象业务流，通脉络

整个家政平台的业务流程可以从客户、商家、交易三个维度进行分析。这三个业务流共同构成了一个完整的家政业务模型。其中，客户流负责获取客户，商家流负责招募商户入驻平台，交易流则负责实现客户与商家之间的交易匹配和履约。整个业务流程如图3所示。

图3 家政平台全业务流

客户流即消费端的流程，涵盖了客户如何找到平台，以及最终如何完成交易的整个过程。这种思维逻辑适用于所有交易平台。图3展示了从获取客户线索，到下单成交的完整流程。

图3 客户流

商家流是供给端的流程，需要从招募商家的角度进行梳理，涵盖商家从入驻到上线提供服务的完整过程。具体包括招商线索的获取、商家培训、合同签订、上线准备以及正式提供服务等环节。商家流的详细流程如图4所示。

图4 商家流

交易流是整个平台的核心流程，也是支付设计的关键环节。它主要涉及用户支付、服务匹配、上门履约、商家结算以及售后服务等多个环节。交易流的详细流程如图5所示。

图5 交易支付清结算流

通过以上分析，我们已经基本了解了一家家政公司的整体业务流程。接下来，我们需要深入研究和思考：“究竟什么样的产品体系能够有效支撑这样的业务流程？”这个问题。

 

3.进而构建产品体系，搭骨骼

在梳理清楚行业和业务流程之后，接下来就需要从多个维度来规划企业的全局产品体系了。对于家政平台而言，基于之前的业务分析，我们可以设计出如图6所示的产品体系。

图6全局产品体系

图6所示的商家端产品则聚焦于商家的线索收集与招商管理，包括线索体系、商家端产品体系以及商家管理等模块。交易产品（涵盖交易层、清结算与资金处理中心、基础支付服务）则实现了用户从下单到支付、从服务匹配到履约、从商家结算到售后服务的全链条内部信息化体系，包含了交易处理、支付服务、清结算管理以及财务处理等各产品组。

 

4.然后规划产品架构 ，生血肉

在完成对整个产品体系的深入分析和洞察之后，可以开始思考产品体系的架构设计了。无论是从产品功能视角、业务划分视角，还是其他任何视角来设计产品体系架构，其核心目的都是为了帮助我们全面、清晰地把握产品的全局。产品体系架构的一个示例如图7所示。

图7 产品体系架构示例

还可以对产品体系架构中的特定模块进行细化，比如后台支撑体系中的后台产品体系。由于这个产品体系主要是为内部员工提供运营支持的，因此在细化时，需要深入分析内部员工当前的工作方式，以及他们期望的工作方式，并基于此来构建相应的功能模块。其架构如图8所示。

图8 后台产品体系细化图

在图8中，业务服务层集成了系统的服务处理功能。这一层会对平台的所有能力进行分组或整合，为各个终端和内部处理提供基础的服务端支持。其产品架构如图9所示。

图9 业务服务层产品细化图

中台服务能力与业务服务层能力在本质上具有相似性，但它们的建设理念存在差异。中台更注重对通用能力的抽象和提炼，旨在实现服务跨业务线的标准化。而某一业务线的服务层能力则更侧重于服务该特定业务线，具有明显的业务线特色。

在产品把控上，我们需要深入细节，细化到页面级别、字段级别，甚至每一个逻辑环节，比如具体到每个系统的每一个页面、每一张表。虽然达到这种细致程度颇具挑战，但并非不可能实现。

至此，我们已经建立了家政产品体系的全局视角，实现了对自我产品能力的高层次提升。

 

5.最后抽象支付通用架构，注灵魂

我们可以更进一步，抽象出一个通用的支付架构，这个架构摒弃了所有行业特定的属性和特点，具有广泛的适用性。然后，我们可以以这个通用架构为基础，进行推演和适配，以满足各行各业支付系统的建设需求。这样，我们就将掌握了一个核心能力——支付产品设计的底层架构能力。通用支付体系架构如图10所示。

图10 通用支付体系架构图

不用不知道，用了都说好，好用，是对一个产品最好的评价！

 

我的图，欢迎大家直接拿去用，用在产品规划里、用在工作汇报里、用在内部培训里......这也是我的图儿们最好的归宿。