什么是架构？

产品架构到底是个啥？

技术架构我们就听过，主要就是描述清楚一个应用群系统的组成部分，各部分的层级关系和职能，那么产品架构呢？

没那么神奇，我们可以先简单理解：产品架构就是对产品主要功能（先不说“能力”吧，得空我们再拔拔互联网黑话）的抽象划分。

可能还是不好理解，我们先举个更具象的例子，看看城市规划是咋样的：

这张规划图里将一块地划分成了很多块，不同的颜色地块规划了不同功能的建筑片区，比如居住、商圈、教育这些。

这时候整体的看这些地块，组成起来是不是就是一个综合的小生态了，按这个规划，这个片区未来可以满足人们居住（功能1）、购物（功能2）、上学（功能3）等需求，理想情况下，这个片区规划好，把其他日常生活所需的功能都规划进来，我们基本都可以在这片区里就完成大部分需求满足了，这就可以理解为一个完整的“产品”。

现在我们用产品的思维来解析下，上面这个场景里用户的需求是啥？也就是：居住、购物、办公、医疗等。

而片区划分配套了：居住区、商业区、办公用地、医院等

这个片区到了一定程度之后，我们就会自然而然给它起个名字，XXX区（非行政区，不纠结这个）。

上面的思考逻辑，用户的需求我们清楚了并且可以大致的划分开->那么就可以对各块需求对应的划分一块规划来满足->最后这个片区完善成了一个“产品”XXX区。

这其实就是产品架构的思考逻辑。

再回到前面说的定义，对产品功能的抽象划分。结合上面的思考逻辑，可以将这里的抽象划分为几个方面：

1、对需求的抽象。

2、对产品功能的抽象，产品功能的抽象又再分为逻辑和数据的抽象。

所以这里可以大胆地将产品架构的设计总结为：对需求全盘理解之后，进行高度的抽象分类，然后对各个分类进行对应的产品设计，完成抽象的逻辑梳理和数据梳理，逻辑和数据最终组成一个有机体，成为产品架构。

产品架构示例

上图是一个产品架构图例子。

先复盘下需求的抽象分类，本次背景是某司在筹备一个统一库存中台，需要在库存中台内完成对全渠道库存的管理，实现全渠道库存共享的目标。

拆解下来，需求抽象为几类：

1、统一的数据中心，管理各渠道销售的产品共享使用库存中台内的库存。

2、统一承接库存相关业务，与WMS完成业务对接。

3、需要有共享、独占、跨仓共享等库存分配的策略。

4、有前端界面完成业务操作。

依据抽象好的需求分类，最终出来的产品架构可以看到分了几层，范围从大到小表示出产品应该具备的功能和逻辑关系：

1、产品跟其他产品之间的交互关系和边界。

2、产品内部主要涉及哪些方面，主要有哪些功能、数据。

需要指出的是，初次构思产品架构时，容易陷入细节思考里面，这是从基于单点需求思考到基于全局思考的转变过程中碰到的问题，笔者在实践中也碰到过这样的情况，多尝试，并且有意识地跳出局限的领域来思考是个很好的解决办法。

同时还需要注意的是，跳出细节不代表对细节一无所知，架构思维是从具体实物中的抽象总结，切忌成为只知道框架不知道具体的空中楼阁设计师。

产品架构和技术架构该怎么建立关系

产品架构与技术架构之间没有太多直接的联系，根据上面的描述，应该可以理解到了产品架构主要用于讲明白这个产品做什么的、需要有什么功能，转化为技术架构还需要技术架构师基于对产品、业务的理解进行架构设计。

但是产品架构也并非和技术架构毫无关系，反而一些边界需要产品对技术有一定理解的基础上提前给到技术架构设计建议。

例如上图，是与技术架构师充分沟通后，根据产品应用的场景特征出具的更细致的架构图，为更详细地表明场景特征。

图中的前台查询是高频、高并发的查询，业务的特征已经决定未来会是这样的，那么产品架构里面就可以将这特征体现出，产品的结构层次就可以做一些设计，比如我们可以用无锁化设计来应对高频的库存访问请求，将扣减库存和后续的单据处理在流程上区分开，这就不仅仅是技术架构师的事情，而是产品也应该开始考虑的事情。

产品经理该懂技术吗

最后引申出网络上经常讨论的一个问题：产品经理需要懂技术吗？

我认为需要懂，并且越多越好。

原因很简单，如果现在你不是产品经理，而是一家公司的创始人，产品要活下来活得好，碰到问题了就不管是什么问题，作为创始人都要解决，PM也一样，越了解你的产品越能将产品做好。

另外计算机科学作为一门学科发展了几十年，先辈们打下了无数的基础，形成了多样的、体系化的方法论，系统的学习能让思维体系更加全面和系统，使得对产品的思考也全面而系统，甚至系统学习才能看到原来野生成长所永远无法看到的高度。