在工作中，我们经常会遇到两类性格特点比较突出的产品经理：

一类是偏业务型的，他们长期深入业务一线，有极强的业务理解能力，对业务的思考和价值预判都非常深入，但在做需求时，很容易和研发产生冲突，因为他们总是站在业务视角，无视系统的实现和扩展。

还有一类是偏系统型的，比如很多做saas和中台的产品，他们有极强的逻辑思维和系统设计能力，但是太偏系统能力建设，离业务较远，设计出来的产品总是不能很好的满足业务诉求，导致业务投诉说系统不好用。

很明显，这两类都很难称得上合格的产品经理，在木笔看来，优秀的产品经理一定是软硬技能兼修的，硬技能包含业务能力和系统能力，软技能包含沟通能力、协调能力、倾听能力、同理心等，我们要不断的学习和修炼，在任何一个方面都不能有太明显的短板，否则，总有一天，我们会在自己最短板的地方掉进坑里。

无论是擅长业务理解和运营能力的业务能力，还是擅长需求分析和系统设计的系统能力，就像天平的两端，都是产品经理必备的硬技能，特别在B端领域，越往高处走，这两项能力越缺一不可。理解业务，才能够更好的支持业务，创造价值，熟悉系统，才能够知道哪些可为，哪些不可为，两项能力结合起来，才能够实现整体最优，走的更远。

本篇文章，我们重点聊一聊系统设计能力里的产品架构。很多朋友听到“架构”这个词，都感觉特别虚无缥缈，这种感觉是正常的，因为它看不见摸不着，更多传递的是一种产品设计思想，但这项思想却非常重要，它能够让我们在业务支持和系统扩展这两个不同的方向上找到平衡点，让我们既能够很好的支持业务，也能够保证系统的完整性。

要理解产品架构，我们从一个经典的童话故事开始说起：《三只小猪的故事》…...

森林里住着三只小猪，它们都想为自己盖一间漂亮的房子。

猪大哥比较懒，从地里找来了很多茅草，为自己铺了一间茅草房，两天就完工了。

猪二哥将门前的树砍下，用木头随便搭了一间木头房子，一个星期也完工了。

只有猪小弟耐心的从山脚下搬来很多砖，然后开始挖地基、建地平、砌墙，然后精心布置，足足花了三个月，才为自己盖起了一间漂亮的砖房子。

这一天，猪小弟正在睡觉，突然听到猪大哥和猪二哥在门外急匆匆的敲门。原来，森林里来了一只大灰狼，想要找食物吃，它先找到了猪大哥的茅草房子，轻轻一吹，房子就倒了。之后它又找到猪二哥的木头房子，使劲一撞，房子也倒了，两只小猪只好逃到猪小弟的砖房子里求救。

大灰狼也跟着来了，在门外使劲撞猪小弟的砖房子，把头上都撞的满头是包，房子却纹丝不动。大灰狼想从烟囱里钻进去，结果掉进了三只小猪烧满开水的锅里，只好灰溜溜的逃走了。

猪大哥和猪二哥这回终于知道不能偷工减料了。

后来，在猪小弟的邀请下，三只小猪把屋顶稍加改造，在上面加盖了两层，变成了三层小楼，从此愉快的生活在了一起…...

故事讲完了，咱们不是为了讲童话，故事的寓意就不说了，重点聊聊为什么猪大哥和猪二哥的房子这么不结实，而猪小弟的砖房子却坚如磐石，还能改造成三层小楼呢？

答案就在房子的结构上，猪大哥和猪二哥的房子虽然建的很快，但基本就是把茅草和木头堆砌一下，就盖成了，这样的房子没有巩固的框架结构，稍微遇到大风和大力就倒塌了。而猪小弟的房子在地平下有很厚的地基，地面还有平稳的地平和能承重的主体结构，这样的结构足够牢固，任凭大灰狼撞破了头，也稳如磐石。

同时，猪小弟的房子稍加改造就从一层变成了三层小楼，也是源自其牢固的基础和坚实的主体结构，做扩展并不动根基，所以才能轻松的完成改造，收留两位哥哥。

了解完房子的结构，我们回到系统架构的问题上来，系统架构和盖房子的原理也是一样的，系统架构就是系统的脉络和结构，架构设计就是梳理出系统的地基(底层核心逻辑）和主体结构（系统主体结构），并在此基础上设计和装修（搭建业务需要的功能和流程）。

好的系统架构就像猪小弟的房子一样，结构清晰、稳定牢固，支持在主体结构上灵活扩展（一层改三层），不好的架构就像猪大哥和猪二哥的房子一样，只是功能的堆砌，看起来能满足当前的诉求，但不成体系，稍微有点外部变化影响，就会崩塌，只能重建，更不要说扩展性了。

根据设计分工的不同，系统架构又分为产品架构和技术架构，通常产品经理负责产品架构，技术架构师负责技术架构，二者的关系如下图所示：

产品架构是在做产品方案设计的过程中产生的，主要是对系统进行合理的模块划分，包含系统主要分哪几大模块，哪些是底层支撑，哪些是上层建设，哪些是主干，哪些是分支，软硬件如何交互等。

技术架构则是在架构师接到系统需求以后，对系统的实现进行技术选型和设计，包含如何进行库表设计、使用什么技术框架和协议、如何划分技术域等。

产品架构的产生过程是产品经理在接到业务需求以后，对需求进行分析，设计出系统的核心功能，然后再对这些功能进行抽象、分组，从而归纳出系统的架构，是一个先具象再抽象的过程。而技术架构是在接到产品需求以后会先开始设计架构方案，然后根据架构方案进入代码开发阶段，最终实现系统功能，是先抽象再具象的过程。

好的架构坚韧灵活，扩展性好，坏的架构脆弱杂乱，问题不断。很多系统的设计，金玉其外，从页面和功能等外表看不出来好坏，但在实际业务运转过程中，会随着业务量级和复杂性的增加就慢慢体现出来优劣了。

在缺乏架构的系统设计中，通常表现为功能罗列、没有主次、相互耦合：

一）功能罗列：系统功能完全是为了应付业务需求而拼凑到一起的，没有规划，没有层级。

二）没有主次：区分不出来核心逻辑和非核心逻辑，只为一味的满足业务，而忽略了系统内部的升级成本。

三）相互耦合：不该耦合到一起的功能相互交织，揉到一起，相互约束，牵一发而动全身。

讲个小A的故事来一起感受一下架构的魔力。

在仓储系统中，入库、出库和库内作业是仓储的三大类业务，每个业务都要处理自己的业务逻辑和加减库存，产品经理小A在设计系统时，将入库、出库和库内模块分开设计，各自处理自己的业务和库存。但由于库存是一个整体，三大业务之间在加减库存时总是相互冲突，导致系统上线后库存一直不平。

同时，小A将入库、出库和库内的作业指令设计到了一个功能里，这样带来的问题是一个系统功能里要兼容不同业务下的不同逻辑，逻辑复杂不说，耦合性还高，经常因为A业务的调整导致B业务也出问题。另外，在部分页面上，负责入库、出库和库内的仓库人员要在一个页面过滤自己负责的单据，再进行操作，经常把其它业务的单据给误操作了，现场痛苦不已，小A更加痛不欲生。

而在一个好的产品架构里，系统是分层而立的，哪些功能是核心主体，哪些功能是外围分支，一目了然。以木笔的经验，产品架构从里往外，可分成底层逻辑、核心业务逻辑和非核心逻辑三部分：

一）底层逻辑：这是系统的最底层的地基建设，承接的是很多业务都公用的底层逻辑，一旦调整，影响面较广，所以应该从场景中剥离出来，不过多的参与业务逻辑处理，保证它的稳定性。比如仓的库存处理、中央库存的分仓、售后的赔付退款、促销系统的发券等；

二）核心业务逻辑：依附在底层逻辑之上，处理与业务相关的主干流程及流程涉及的单据、状态变更等，调整后会对当前业务产生较大的影响，但不会影响其它业务，在设计系统时，核心业务要尽量保持独立性，避免和其它业务交织到一起，以免相互影响，同时，也要尽量保证主干流程的稳定性，不要轻易调整。比如入库流程、出库流程、售后退款、维修流程等；

三）非核心逻辑：其它不对业务主干产生影响的非核心逻辑、辅助流程、工具等，在核心业务逻辑的基础上，可根据业务需求灵活调整。如增加设备、自动化执行、批量操作、记录日志等。

需要强调一点的是，核心业务并不等于核心逻辑，很多功能对业务很核心很重要，但在架构里，只是一个非核心的逻辑，二者是两个维度的划分，并不矛盾。

继续小A的故事。

正在小A痛不欲生的时候，救星老L入职了，经过一番调研和分析后，老L开始对仓储系统的架构进行梳理，只做了两件事，所有的问题就迎刃而解了：

一是将库存的处理独立出来作为底层逻辑，并抽象出加库存和减库存两个服务，这两个服务只做库存的加减和事务处理，不涉及任何业务，所有库存变动的场景都必须调用库存服务，通过库存事务处理来保证库存的准确性；

二是把入库、出库和库内业务按照场景拆分为不同的模块，并设计成不同的菜单，各业务之间相互独立，互不干扰。如此一来，现场再也没有出现过误操作的情况了，而且当某个业务接到新需求需要升级时，也不会影响其它业务。

经过1个多月的调整，仓储系统终于稳定下来，再也没有出现过大问题了，这就是产品架构的魔力。

通过前面的故事，相信没人会怀疑产品架构的重要性了，产品架构设计的目标有两个：结构清晰、通用扩展。

结构清晰：将复杂的业务进行分类，并区分出主次，让系统的结构更加清晰。

通用扩展：将重要的核心逻辑设计的尽量通用，减少业务逻辑的干扰，以便保证其稳定性，后续也能接入更多的业务场景。

如何设计产品架构呢？木笔总结了一个9字心法：列场景、提主干、附功能。

（一）列场景。在需求调研和分析的过程中，尽可能全的将所有业务场景都罗列出来，比如仓库系统包含入库、出库、库内流程，入库流程又包含收货—验收—上架几个环节，在上架环节需要加库存，这些都是场景。

（二）提主干。把场景进行分类，找到各个场景都公用的逻辑，抽象成公共模块，并剥离出业务特色，变成底层逻辑；然后对每个业务进行设计，剥离出业务的核心流程和非核心逻辑。这样一来，系统就被分成了底层逻辑、业务核心逻辑和非核心逻辑三层了。

比如在仓储系统中，商品、货位基础数据，以及库存处理是所有业务都公用的，这些功能就是系统的底层逻辑；入库、出库、库内这几大流程又各自都有自己的单据、节点和状态，这是每个业务的核心逻辑。底层逻辑和业务核心逻辑就像房子的主体结构和承重墙，也像树干和树枝一样，构成了系统的主干结构。

（三）附功能。按照梳理出的系统结构对场景和功能进行划分，将业务核心逻辑附到底层逻辑上，再将非核心逻辑附到业务核心逻辑上，就像拼积木一样，便能按照产品架构实现所有系统功能。

比如在梳理出仓储的基础数据和库存处理等核心逻辑后，将入库业务嫁接到基础数据和库存处理上，然后在入库业务基础之上衍生的其它功能如收货信息录入、上架操作等，便是非核心逻辑了，这些功能虽然是业务最常用的，但因为不涉及核心逻辑，所以可以跟随业务需求随意调整，就算推倒重来也影响不大。

以下是按照9字心法设计的仓储系统产品架构：最底层是所有业务公用的基础数据，第二层是在基础数据之上设立的库存处理和策略配置，第三层是在库存和策略之上开展的入库、出库、库内业务和异常处理功能，最上层是辅助进销存业务开展而设立的人工作业模式和设备作业模式。

如何验证一个产品架构是不是好的产品架构呢？木笔给几个评判标准供参考：

（一）主次分明。好的架构有很清晰的结构，底层逻辑、核心逻辑和非核心逻辑有很好的定位，不是混在一起的。

  (二）逻辑通畅。好的架构要支持业务流程连贯，除了一些必要的强校验外，应极少出现分支和卡顿。对于那些影响主流程通畅的子流程，应该剥离出去。

（三）边界清晰。不同业务模块之间相互独立，保证模块内高内聚，模块间低耦合。

（四）扩展性好。好的架构一定是面向未来的，在保证主体结构稳定的前提下，能够兼容更多业务场景以较小的成本接入。

（五）持续迭代。好的架构不是一成不变的，而是可以随着业务的迭代节奏不断进化的，时刻保持与业务的同步性。

做系统设计时，业务理解固然很重要，但架构设计也同样不可或缺，业务理解帮我们贴合业务创造价值，架构设计帮我们分清主次走得更远。当我们从功能实现转为梳理产品架构的时候，就是产品能力跃迁的时候了，一起加油吧。