我的产品架构观：模块化高内聚低耦合-技术圈

当我们讨论一个产品架构的时候，我们既不是站在用户的视角去讨论这个问题，也不是站在老板的视角去思考商业模式，而仅仅是从一个工程师的角度，去讨论这个产品应该以怎样的结构去搭建，这是我之前很少思考过的命题。

用户视角看过去，这个产品是上线的，且这些产品信息是特地展示给用户的，而与之伴随的过程和后台信息，用户看不到。老板视角看过去，这个产品服从于某个战略，身上贴着两个标签：成本和收益。

而从工程师的视角看过去，这是一个系统。这个系统如何从图纸到地基到高楼大厦，都是这个系统演化过程中的信息。工程师固然要作为用户去体验、要作为员工去思考成本和收益，但工程师的最大满足，在我看来，就是以一种高效和科学的方式，管理整个流程。流程管好了，和你配合的团队才算是管好了。

我以前没有去认真思考过产品架构的问题，一方面是因为我做的很多产品都不需要从0到1，绝大多数都是对现有的产品做优化，而优化的目标，要么是优化用户体验，要么是改善成本和收益。但在具体执行的过程中，总是会出现研发过程的磨损。而这种磨损，往往对团队士气是一种巨大的伤害，如果需求成功了，胜利会掩盖一切矛盾，但如果失败了，怨气会在心里慢慢累积。

曾经我以为这种研发过程的磨损，是项目管理上的问题，能通过更好的过程管理来减少磨损，抑或是通过更好的沟通技巧来解决。但我渐渐觉得，我似乎忽略了产品架构设计对研发过程的影响。如果一个结构本身不合理，可能就会注定产品方案设计和技术方案设计之间，会产生更多的偏差和磨合，自然而然就反馈到了研发过程中。

为了让你能更容易理解，我以最近负责的一个讲书会员产品的搭建过程为例，来说明我的产品架构观以及这种观念对研发过程的影响。

一

市面上有很多讲书会员产品，可能最著名的是我现在的公司，樊登读书。

从用户视角来看，这个产品就是能够让我可以用听的方式去了解一本书的精华内容和讲书人对这本书的分析。从老板视角来看，这个产品的成本包括版权、讲书人签约、产品研发运营成本等等，收益主要来源于用户付费买会员资格。

但从工程师的角度来说，理解用户视角和老板视角，都没有办法直接帮助自己去开始一个讲书会员产品的设计。产品经理需要把这件事情，变成程序员可以看的懂的图、表、原型、描述等，而程序员又进一步以更专业的方式开展任务设计、拆分，最终到一行行代码。

最近我在操盘公司一个新的讲书会员产品，与更经典的讲书产品相比，它是日更的形式，跟传统日更形式的付费专栏相比，它又是以书籍的形式呈现出来。刚刚接手这个产品的设计工作时，我就在想我的设计需要用一张图就可以说清楚，清晰的结构，在跨团队的沟通中会让大家快速形成共识，并且当问题出现时，也能快速定位到问题。

而这个图上的内容，就是我的产品架构。

二

先聊聊模块化。

抛开产品本身不谈，我们所在的社会本身就是模块化的。无论是由无数家庭组成的整个社会，还是由多个部门组成的整个公司，都是模块化的。模块背后是秩序，秩序背后是逻辑，产品是讲逻辑的，故产品的背后一定是模块化的。

对于一个讲书会员产品来说，我将它划分为如下几个主要模块：资源、商品、用户、体验、营销、订单。下面分别做说明。

资源：这是对内容的管理。对于一个日更的讲书产品来说，资源管理的主要目标是节目和书籍。节目是最小播放单位，即单次播放是建立在节目上的。书籍是节目的组合，在资源上配以自己的包装内容，例如封面、介绍、标题等。基本上管理好书籍和节目，也就管理好了一个讲书产品。

商品：这是从内容到商品的转变。商品是可售卖的，具有交易价值，这是资源和商品最重要的区分。如果一本书可以单独售卖，那这个书既是资源、又是商品，但对于一个会员产品来说，用户买的是会员身份，这个身份的权益是可以畅听资源。

用户：C端产品直面用户，用户的管理是核心。从C端产品的角度看，用户模块主要是对用户基本信息的管理和操作，但从讲书会员产品的角度看，用户模块更重要的是对用户会期的管理和操作，在会期的管理上，我认为可跟库存产品对应来看，用进销存的概念，去理解会期的新增、消耗和现值。

体验：这是用户所能感受到的全部。还记得我们前面说的，从用户视角看产品么，其实看的就是对应产品系统内的体验模块。对体验的进一步拆分，我会划分为“功能、页面、端”三条线。讲书产品的功能体验包括播放、互动、行为沉淀等；页面包括产品首页、会员付费页、书籍详情页和节目详情页；而端则主要是客户端、web端、pc端、ipad端等。

营销：这是从商业层面出发的模块，营销的目标是为了扩大品牌知名度，促成交易。讲书会员产品常见的营销方式有，“优惠券、礼品卡、免费会期、组合销售等”

订单：这是极其非常重要的一个模块，怎么下功夫都不为过。本质上订单就是一个记录，在用户付费购买会员的那一刻，这个记录就生成了。为什么说它很重要呢，因为订单是跟钱关系最大的一个模块，订单不准，业务基本就废了。就好像你开一家实体店，装修、进货、陈列、动线，你说重要么，重要的，但是如果账管不好，基本这家店存活不了多久。

讲完这么多，你一定有疑问，为什么是这么几个模块。

三

再聊聊高内聚和低耦合。

我第一次听到这个概念，是我在学C语言的时候。对C语言来说，最重要的概念便是函数了。函数就是一个模块，函数和函数之间可以互相引用，通过参数实现连接。

作为产品经理，我跟技术打交道的第一堂课就是了解了前端和后端的区别。对于技术架构来说，前端和后端是独立的模块，彼此通过接口产生连接。

高内聚和低耦合，并不一定是最合理的模块划分原则，就像我们小时候做归类题一样，标准不同，归类的结果也不一样。但是，高内聚和低耦合是技术最友好的模块划分原则，我希望解决的是：减少产品方案和技术方案之间的偏差和磨合，先奠定一个合理的架构，再思考通过项目管理和非暴力沟通，来优化整个产品研发过程的效率。

什么是高内聚，我的理解是，单个模块是完整并且相似。如果这个模块可继续划分为子模块，那子模块之前是相似的。低耦合，我的理解是，模块与模块之间通过类似“接口”这样的概念产生连接，就像两个岛之间通过桥连接，而不是一个岛和岛上一个广场的关系。

上面的话有点抽象，回到讲书会员产品吧。

还记得么，资源包括节目和书籍，无论是哪一个，他们都是一个内容方向的概念，你绝对不会把节目和优惠券放在一个模块内，因为他们几乎无相似度，聚合度很差。再者，商品和资源之间，通过一个配置项就可以解决。

当然，具有会员身份的人可以畅听所有资源，这是一个业务规则，假使会员只能听其中的部分书籍，那在配置会员商品的时候，也只需要做添加书籍的配置就可以了。

另一方面，讲书会员产品本身跟其他系统也是高内聚和低耦合的关系，上面提到的优惠券，一般是有现成的优惠券系统，而讲书会员要可以使用优惠券，只需要在优惠券的配置上增加这个会员产品就可以了。当然，这也很考验优惠券系统本身的扩展性，这又是另一回事儿了。

四

最后，我说说自己为什么要写我的产品架构观。

我经常听很多人分享在大公司做螺丝钉的体验，其中最常听到的一句话就是，一个产品，无论谁来做，最后总能做出来。也就是说，很多时候我们太关注输出和价值，但是对设计过程却关注得不错，但在我看来设计过程却是极有魅力的，也非常考验产品基本功。

怎么跟大家说这种感觉呢，我引用一段《三体》中的情节吧。

人类在未来的某个时刻，在太空的某个角落，意外的发现了四维空间碎片，某个宇航员意外的踏入了这个四维空间。他说，那是一种有语言无法描述的感受，在四维空间里，一切三维世界中的物体都是透明的，这种透明是原子纬度的。从三维到四维，这种信息的爆炸是如此之强，以至于他们再次回到三维空间时，都产生了空间幽闭感。因为那个纬度的信息太丰富了，以至于眼前的世界像一方紧闭的高墙。

为什么要关注产品的设计过程中，又为什么要有自己的产品架构观呢，就是希望作为产品经理，我看到的不再仅仅是用户体验和商业价值，而是这个产品所走过的每一步，破除那方高墙，真正认识你所负责的产品。

我的产品架构观：模块化 高内聚 低耦合

我的产品架构观：模块化高内聚低耦合