深度长文（一）：什么是产品架构？

我们常常会看到“产品架构”这个词，乃至能看到有些公司专门有一个叫做“产品架构师”的岗位。

提及架构，很多人会以为很虚，那么到底什么是产品架构呢？

我们知道开拓有专门的一个岗位叫技能架构师，推己及人，我们先看下技能架构师是干嘛的？

架构师能对线上业务进行模块划分，系统拆分重构，并做好干系高可用的方法，以担保系统的稳定，安全、高效地运行。
大略来说这是一个既须要掌控整体又须要洞悉局部瓶颈并依据详细的业务场景给出办理方案的团队领导任务。

先来看下技能架构师的几个核心关键字：

权衡与平衡抽象、建模与设计预见性和前瞻性简化之美模式与重用质量、效率与资源敏捷、迭代与演进前构与重构

实质上，技能架构的关键字同样适用于产品架构。

技能架构中有一句比较盛行的话：统统分开业务的架构都是耍泼皮，产品更是如此。

我考虑把“产品架构”写成一个系列文章，这篇文章先会整体讲一下产品架构的基本观点和方法，对付上述关键字的深度解析。

一、什么是产品架构？1. 先来看看“人”的构成

（1）从原子水平60多种主要的，如：氧占约65%、碳占约18%、氢占约10%、氮占约3%，(这四个元素约占人体96%)。
其他元素较少，但也很主要。

（2）从分子水平上说，水约占人体约60%，碳水化合物和脂肪占人体约14%，蛋白质占人体约17%，其它如维生素、矿物质、纤维素等。
这些是人体的七种营养素，这七种营养素在人体中每一个都扮有非常主要的浸染，不可短缺，也不可过多。

（3）在细胞水平剖析，人体由细胞、细胞外液及细胞外固体组成，细胞是组成人体的基本单位。

（4）在组织水平剖析，人体是由四大组织组成，即上皮组织、结缔组织、肌组织和神经组织。

（5）在器官水平剖析，多种组织以不同的编排形成器官。
人体内有很多器官，如胃、肺、心、肾、脾、胰、肝、膀胱、尿道、子宫等。

（6）在系统水平看，共有9大系统。
如消化系统、呼吸系统、脉管系统、内分泌系统、神经系统等等。

我们以消化系统做一个比喻，就很清楚了。
先来看下消化系统的示意图：

我们会创造人体消化系统：

由很多器官组成：由消化道和消化腺两大部分组成。
能形成一套自发的运作流程：食品进入口腔、咽、食道、胃、小肠（十二指肠、空肠、回肠）和大肠（盲肠、阑尾、结肠、直肠、肛门），末了排出肛门，流程结束。
个中消化腺分布在消化道管壁附近，并将消化液排入消化管内帮助消化食品。
有必要的功能浸染：食品的消化和接管，供机体所需的物质和能量。

2. B端业务体系的构成

“人体的消化系统”非常像“B真个业务体系”，比如一个患者来诊所看病：客户须要先在网上预约，然后在约定韶光到诊所登记、看诊、付费、取药，末了离开诊所。

全体业务流程由很多”器官”组成：“软性器官”比如预约、登记、看诊、付费、取药等模块，“硬性器官”比如年夜夫、护士、药师，以及对应的药品、材料、叫号硬件、打印机等等。

这些软性和硬性的“器官”在全体流程体系中相互协同发挥着不同浸染，才能够让患者在流程中顺利的今后推进，直至到达流程的终点。
这套业务体系发挥的浸染便是有序的让患者得到诊疗。

说完了人的消化系统，再反不雅观B端业务，我们会创造很多相似之处：

消化系统——业务流程体系组织——底层根本模块器官——一级业务模块细胞——二级业务模块分子——页内tab（三级业务模块）原子——字段

这里涌现的“底层根本模块”、“一级业务模块”、“二级业务模块”等实质上便是对业务的分层。

（1）定义层级

一样平常来说B端产品的分层基本便是按照上述（2）-（6）的维度进行划分的，可视业务繁芜程度适当增加或减少层级。

（2）完身分层

将同一平台下、同一职能下、同一角色下具有高度关联的子模块分到同一层母模块中，这就须要你作出判断哪些模块是业务相似度和关联度都非常高的。

事实上（2）-（6）构成了业务的构造，每个维度模块们的任意一个模块都是构造中的节点，他们之间相互独立，但又相互关联、相互影响。

类似打算机网络的构造：

以是我们看到：B端业务的核心在于业务流程+构造，且业务塑造的构造是为业务流程而做事，什么样的业务流程决定什么样的业务构造。

3. B端产品架构的构成

产品架构便是对业务的构造化抽象！
根据业务体系的剖析，我们看到实在TO B产品末了便是要抽象出准确的流程+构造。

我们常常说一个功能，或者一个业务场景的办理方案，实质实在便是一个小系统。

在这个小系统中，上面那些“底层根本模块”、“一二三级业务模块”、“字段”等各种节点支撑了这套业务流程，从而使得这个功能（办理方案）能够形成闭环，并顺利的运转起来。
而浩瀚功能／办理方案又构成了一个产品整体，就像这些浩瀚的相互独立、相互浸染、相互依赖的小系统组成了一个大系统。

再强调下：大家要记住TO B业务中，流程是核心，构造都是环绕业务流程进行划分和设计的。
以是流程的优先级是大于构造的。

二、如何绘制业务流程图？

一款产品的紧张核心业务流程的脉络一定是非常清晰的。
比如：这是一款自助开票软件，那么核心流程一定是用户扫码自助填写开票信息，并由系统完成开票，并发送到用户手机／邮箱。
比如：这是一个电商平台，那么核心流程一定是选购商品，添加购物车，下单完成支付。

当然B端繁芜的业务场景每每会有多条主业务流程，并且附带了很多分支流程。

我们在画流程的时候，首先要定义横纵向维度，其次便是划分模块。

一样平常来说，流程图的纵向维度可以做本钱能性能部门／角色／平台层；流程的横向维度可以进行平台层／模块层的划分。

以下图“拼团功能”为例，横向是平台层，纵向是模块层，这是一个跨平台跨模块的产品需求。
可以看到在这个业务流中，一级模块划分出了营销、商品、订单、统计模块。
实质上划分模块便是对业务流的解耦。

三、模块划分的基本原则？

根据上述流程构建的一个非常大略的产品构造图：

（这个构造图略去了很多，只是想做个示意）

这个中我们看到划分出来了“商品”、“活动”、‘订单“、”统计“，加上“商家管理”、“推送模块”共6个模块。

那么在划分模块的时候我们要关注哪些原则呢？

1. 关注低耦合

（1）什么叫解耦？

藕断丝连，这个词语非常形象，业务体系就像一个藕，业务内部的模块之间的相互关系就像藕丝一样错综繁芜，又相互依赖、联系紧密（耦合），解耦便是把藕折断，分成独立的两部分。

实质上它是把场景不同、业务属性不同的模块进行拆分，归为不同的两类，但是由于两者都为业务流程做事，这个中难免会有相互协同的地方，于是就会有丝连的情形，这种丝连表示在流程中。

（2）解耦的浸染？

解耦能够让场景更聚焦，让功能模块更聚焦垂直业务。
比如积分模块，凡是跟积分干系的统统业务需求，如无分外情形，都可以被归集到积分模块中。
对付须要用到积分的其他业务，则可以通过开放一些标准接口供其他业务调用。

最忌讳的是把另一个业务（随便举个例子比如活动模块：抽奖活动，抽中就送积分）和积分模块聚合在一起，这会导致，任何一个模块要做修正和迭代时，都会最大程度的影响另一个模块，导致无论产品还是技能的迭代本钱都非常之高。

2. 关注角色场景

对付不同职能／角色不同的利用者，他们的业务场景，事情内容一定会有差异，我们不能把他们各自利用的功能权限放在一个模块内，这会带来很多问题：

A和B的模块发展方向完备不同，导致模块的发展南辕北辙；A和B的模块关联度很低，产品功能上两者聚合在一起显得毫无意义；用户不肯望A的模块可以被B看到和利用，两者的权限不同，但是由于同属一个模块而导致权限非常难划清边界。

以是对付不同职能／角色的利用者，只管即便将他们各自所要用到的产品模块拆分开来，保持各自的独立性，是模块划分的一个主要依据。

3. 关注数据流

业务流程可能会以一个人、或一个主体为中央进行流转。
而数据流是隐蔽在表象之下的另一个流程，他因此数据为中央进行流转的。

一样平常来说，C端产品的数据流，基本只须要考虑前后台的数据流转情形即可。
但是B端就会繁芜一些，B端saas产品数据每每贯穿C端功能，还会涌现跨平台、跨模块的数据流传。

数据流的浸染，能帮助你更清晰的划分模块。

四、如何设计产品构造？1. 产品构造设计的范围

产品构造设计包含多层维度的设计，紧张有如下5层维度：

系统层面的构造——如何分平台／系统；版本层面的构造——如何分版本／权限；模块层面的构造——如何分模块／二、三、四、五级模块；页面层面的构造——如何分页面／页面信息；产品内在逻辑构造——如何用逻辑串联。

产品构造的在用户真个展现便是信息构造。
这点相信大家都懂，无非是页面层级、页面内部信息层级的划分、信息内容的分类和展示。

其次便是产品内在的逻辑构造：

比如某个配置项该当放在功能模块内还是根本模块内？比如在连锁系统中，会员是放在连锁维度还是单店维度？比如直接在营销活动中创建电子券，还是先在电子券模块中创建，然后营销活动进行引用？

这些实在都属于产品功能层面的架构。

2. 产品内在逻辑架构设计的7个核心原则及10个案例易用性——从用户利用体验层面考虑；可扩展性——迭代、修正的本钱最小化；技能实现性价比——技能实现本钱是否过高不匹配功能代价，按性价比高的去设计；普适性——每个单元模块是否可以被其他单元无限重用；熟习业务——违反业务习气的逻辑设计不能涌现；节制产品发展方向——预见产品在中短期内的发展方向，提前考虑进去；从大略到繁芜——任何一个产品都是从最小MVP开始的，千万不要在开始就架构一套繁芜的系统。

关于一些构造设计上，我给大家列一些比较高频涌现，比较常见的B端产品（不同纬度的产品架构思路）小例子：

（1）比如我们有一套面向商家的门店经营管理系统，这时须要一个有一个卡券平台，跟门店管理系统中的业务有着密切的关系，这个时候你该定义这是一套系统还是两套系统？他们的关系是什么？边界在哪里？

（2）比如我们做了一套诊所管理系统，后续要垂直化专科式发展，那么到底是通过拆分版本，完备一个科室一个独立的版本？还是做在一套系统里，然后通过权限划分 更合理呢？这实在便是产品架构的一部分

（3）比如对付电商类的saas，很多是非协作型的，也便是说模块之间并没有严格的强联系，相比拟较独立，独立作为一个B端业务闭环，可单独利用。
但是像诊所saas，则是协作型的，即业务流程涉及到多模块多角色，每个角色都须要在流程中承担一部分事情职能。
非协作型和协作型的系统设计的思路也是不同的

（4）比如我们在设计电子券的时候，我们是通过一个步骤完成创建+投放，还是通过创建一个步骤+投放一个步骤完成流程？背后的考虑成分是什么？

（5）对付一些业务流程的设置项，是放在后台该业务模块维度，还是根本设置模块的维度？

（6）比如原来要设计商品管理模块，考虑的紧张是单店模式，跨店的商品管理是隔离的，但是当跨店客户提出想要统一管理商品，并可以支持总分店和分店之间的商品调拨的时候，单店商品管理的设计方案就无法支撑这样的业务模式，须要做大规模的底层改动

（7）确定维度，比如哪些指标是单店维度，哪些是机构维度，比如预约是放在后台“诊所管理”里面，还是单独放在后台“预约管理”中？放在哪个维度又是基于哪些缘故原由考虑的？

（8）业务的不知足性，比如我们在做一款电子券的时候，考虑了线上场景，但是还要考虑线了局景，这就须要电子券模块下须要投放到线上（多个渠道）、线下（二维码、短信等），那么渠道后续可能会进行变更，那么如果我们把创建+投放一步完成，那么未来我们要改动渠道，就会影响全体卡券流程，如果我们能分2步，那么只须要对第二步投放进行修正就行，这样系统的可扩展性就会强很多

（9）比如对付订单模块的架构设计，是否能够支持各种营销活动：满减、卡券、积分抵扣等，具备足够强的业务原谅性

（10）重复被利用的模块，如何避免重复造轮子！
比如电子券模块，在很多营销活动中都会用到，比如短信模块，在很多业务中都会用到，那么这些被高频用到模块就该当抽离出来，而不是每个业务环节中都去做一遍。

3. 产品架构必备能力

当然作为一个产品架构师，要完成这些事情，对付能力的哀求也是非常高的，最紧张的4点：

懂业务；预见能力，预见未来业务流程、业务模式的变革趋势；成熟的B端产品构造化思维；懂技能事理，懂技能事理最大的好处便是能大概评估这个设计方案的技能本钱，并推动自己选择更得当，投入产出比更低的设计方案。

总结

产品架构实在是一个非常繁芜而伟大的话题，这篇将近5000字的文章也只是起了个头。

我想说的是，产品架构不但是给产品搭个框架，他涌如今产品设计的方方面面中。

通过这样的架构思维帮助产品最均衡的匹配用户的多样性需求，匹配公司的大研发资源，匹合营适的机遇把产品做到得当的程度等等。

这是一个别系性的工程，好的架构能够支撑业务发展多年而不重构，更能让用户啧啧夸奖。

我想这便是产品架构的魅力吧！

作者：司马特小队，丁喷鼻香园高等产品经理。
微信"大众号：司马特小分队

本文由 @司马特小队 原创发布于大家都是产品经理，未经容许，禁止转载。

题图来自Unsplash，基于CC0协议。