产品的底层逻辑设计其核心在于，对数据和模块的分割，以及服务能力的设计和调用关系的搭建。

先啰嗦一下

产品的底层逻辑，指的是一个产品对所支撑的业务过程的抽象，是一个产品从数据维度对功能模块的分割。

各模块接收的外部数据（比如用户通过页面输入的、作为被调用模块从其他模块接收的等等），维护的内部数据（比如订单模块内部维护的：订单ID、订单状态、交易双方ID即用户的索引值、订单时间、金额等等）和该模块提供能的服务能力（依然用订单模块的例子，该模块可提供各内部数据的查询服务、由外部触发的更新订单状态的服务等等），将上述的服务能力，以模块之间的调用关系结合起来，形成了一个产品支撑的各种功能的实现过程。

无论是直接面向C端用户的产品（比如社交、媒体等等），还是一个To B的应用（第三方支付、企业CRM、），甚至是一个产品体系中的分支，都包含了一个自有的底层逻辑，通过数据接口相互关联。广义范围内来看，个人认为，To B的产品底层逻辑相对To C的产品，数据结构与调用关系普遍更为复杂且到达前端的路径更长。而C端产品，往往更关注前端交互，底层逻辑单薄，这也就是为什么，C端产品甚至只凭一个交互稿就可以完成与开发团队确认需求的沟通（当然这也没什么错，毕竟这只是沟通的手段）。但一个B端的产品经理，如果只输出原型，就请在评审会上注意人身安全，程序员爸爸们大概是不会甘愿从寥寥的原型批注上理解错综复杂的数据迁移和订正逻辑的。

以下，是作为一个从To C向To B的业务转型的产品经理关于产品底层逻辑的一些经验，整理出来供诸君参考。

下面说正事

我们先来看节选自一个PRD的部分目录结构：

1.模块分解

2.模块名称：

2.1模块功能描述

2.2模块定义数据

2.3服务能力

2.3.1服务名称

2.3.2服务业务含义描述

2.3.3适用场景

2.3.4前置要求与能力触发机制

2.3.5数据及数据有效性要求

2.3.5.1外部数据

2.3.5.2内部数据

2.3.6处理过程描述

2.3.7调用后续模块

2.3.8数据输出

2.3.9异常情况以及处理

上述目录传达了几个概念：模块、服务、数据

模块：

模块定义了以业务含义高度关联的核心数据范围，以及该数据范围内可能发生的处理过程，也就是服务能力。

比如，一个企业账号信息模块，包含了该账号ID（即系统赋予此账号的索引值）、企业名称、账号类型、角色标识（与角色权限关联）、相关的注册信息（联系方式、地址、规模等等）、相关的系统行为信息（登录历史、操作历史等等）。在上述前提下，在核心数据范围的设计策略上，普遍遵循模块间解耦的原则，也就是模块之间维护的核心数据保持独立和隔离，避免重复存储和间接查询。

服务：

服务定义了以某个模块维护的核心数据为基础，发生的初始化、查询、删除等等处理过程，可能存在相应的外部数据输入和内部数据，以及经过服务处理过程的数据输出。依然以企业账号信息模块为例，该模块提供的服务可能包含，初始化服务（即创建某个新的企业账号，也就是由用户注册行为触发的底层数据行为）、对某个字段数据的查询服务（通过外部输入的索引值查询该账号的相关信息并给出输出）、修改某个字段数据的服务（也可能存在不可修改的数据，例如账号ID）、删除服务、更新账号状态服务、更新操作历史服务，以及可能存在的其他服务。服务的设计依赖对产品所支撑的业务过程的抽象，即该业务流中所包含的数据，以及数据是以何种形式被输入和被加工并输出的。

数据：

这里通过一个简单的功能来阐述，某个社交类产品里面，存在一个加好友的功能，并且用户可以自由定义是否允许我的好友浏览我的朋友圈。下面我们分析一下，这个看起来很简单的功能所涉及到的数据。

首先，区分用户的账号类型，比如我们通常使用的个人微信号很明显属于同一类型的数据结构，且注册方式、登录方式、验证方式相同，微信公众号的账号体系却有所区别（同时存在关联，这里暂时不讨论复杂的情况）。在这样的前提下，我们可以认为发起好友申请的账号和通过该申请的账号属于同一个模块中维护的同一种类型的数据，这里暂时命名为账号信息模块。同时，每个账号都有一个与之关联的好友列表，这里暂时命名为好友模块。这两个模块中维护的部分核心数据见下图：

通过对模块的分解和对核心数据的定义，添加好友这个功能，我们可以将底层逻辑解析为：

1.查询账号信息服务

即通过登录状态的账号ID（理解为该服务的外部输入），查询至关联的好友列表ID，并输出。该账号的好友，也是通过调用该服务，查询关于账号的其他信息（可能包括昵称、性别、年龄等等）。

2.查询好友信息服务

通过前述服务输出的好友列表ID（索引值），查询至关联的好友信息，并输出该模块部分核心数据：好友的账号ID和是否允许其浏览朋友圈（布尔值）。

3.初始化好友信息服务

即通过外部输入的账号ID，是否允许其浏览朋友圈（通过用户的设置），新建该账号关联的好友列表中的一条数据并保存。

4.更新设置服务

在该权限允许修改的前提下，即更新“是否允许浏览朋友圈”这个数据，更改对某一个好友对该账号的朋友圈的浏览权限。

通过上述几个服务的设计和互为输入输出的调用，方可实现所谓的“加好友和屏蔽朋友圈”这个简单的功能。且此处讨论的是最简单的情况，账号类型唯一，好友申请不需要通过，仅有一个权限设置，考虑到实际设计过程中会出现更为复杂的情况，比如多种账号类型的关系，是否采用双向的好友关系，亦或是类似“关注”的单向关系，以及是否需要通过申请，是否存在多个权限设置，权限之间是否存在交叉关联。则需要在上述模块中设置更多的数据和服务，以确保功能的正确实现。

我说完了

产品的底层逻辑设计其核心在于，对数据和模块的分割，以及服务能力的设计和调用关系的搭建。回归到诸位作为设计者身上，考验的是产品经理对业务的抽象能力，以及对定义数据的高度透视。个人理解其，作为对需求的描述方式，需要结合与底层逻辑高度一致的交互说明以及前端信息结构才能够对整个产品做出清晰的阐释。

简洁的界面并不能代表最优秀的设计，清晰高效的底层逻辑，代表了一个产品经理对自己作品的终极思考和对细节的考究。如何规避产出冗余的数据，交叉重复的服务能力，模块分解的颗粒度选择等等诸多细节，都是1-3岁的产品经理们趟着浑水一步一步摸索和积累，从而内化为我们所谓的“逻辑能力”。

过去曾经面试过很多产品方向的新同学，往往大家都存在着觉得自己的逻辑能力还不错的幻觉，个人的经验是，逻辑能力也许是可以天生的，但更多还是需要在实践中慢慢打磨。近日无事，再回头看自己曾经做过的设计，老脸一红，不知当初何来的勇气敢用这种东西打发程序员爸爸。

感叹前路漫长，与君共勉。

本文由 @MyLady 原创发布于人人都是产品经理。未经许可，禁止转载。