今天在队内和产品妹子聊到了用模块化思维下的产品逻辑来思考产品，索性就展开来聊一聊这个事情。
其实这就涉及到所谓的产品方法论了，每个产品人对做产品的方式方法和思考方式都有不同的解读，这里我阐述所用到的都是我自己的表意方式，以及我自己是怎么理解产品逻辑的的，这些都只代表我个人的想法，而且都有可能是错的（可能明天我就变想法了）。
首先要说明白什么是产品逻辑：产品逻辑就是能够完成一个完整的可实现的产品的方法论集合。（PS. 完整的涵义非常丰富，包括用户体验、功能完整性、满足业务需求等，而可实现的则包括技术、设计、资源等各个方面）。
接下来，要说清楚什么是产品（当然是互联网产品）：产品即业务逻辑+信息+展现（设计+交互）的集合。（类比如什么是程序：程序即数据结构+算法的集合）
模块化思维（面向对象，这里的对象即模块）是一种方法论模型，将一切产品的组成要素模块化。模块不是死板的、一成不变的，而是在一定的合理阈值（就是度，每个人心中都有自己的那个度）范围内可以完整表达一个产品要素或者产品要素的集合。模块之间的关系是相互独立又嵌套关联的，一个功能可以称之为一个模块，一个系统也可以称之为一个模块。模块一定是可以通过模块化的思考聚合分解出来，模块是一个产品架构的元单位。
现在，我们就以知乎app为例，流程式地分析一下它的搜索功能：
1. 打开知乎app，在tab1的顶部就是搜索入口，可见知乎的产品经理对于搜索问题、话题或人的重视（可对比旁边的加号是提问按钮即提问入口），这就涉及到对产品的理解，知乎app更多的是解决看内容（学习）的需求和媒体属性：
2. 点击搜索框跳转到搜索页，这里可以看到当搜索框里面没有文字内容的时候，会显示历史搜索，以及分为两个维度去展现搜索结果，即内容和用户:
3. 当在搜索框中输入内容过后，判定为搜索框中有内容时，即发起搜索（响应式搜索，关乎用户体验，更快地搜索），在内容维度下则显示出话题结果（考虑显示数目和排序）和问题结果（考虑排序）。点击相应的item list中的内容跳转到相应的item详情页。并且提供发起问题入口，这样的考虑是当键入内容没有合理结果时，用户可以在这里直接以键入的内容发起提问：
4. 当切换到用户维度下，将展现和搜索内容相关的用户，其他与3相同:
5. 如果改变搜索框内的内容，即增删搜索框的内容，相应的结果也将变化：
如果落地到流程图上，应该是这样的：
以上，是以一个流程化思维的角度来分析了一个产品的功能。
做技术开发的时候，有面向对象和面向过程。面向过程的编程范式也可以完整开发呈现出所需要的功能，但是在做扩展、考虑重构和复用的时候往往很困难，并且随着代码积累的越来越多，将变得越来越积重难返、冗余和晦涩，这个非常类似于现在很多产品只考虑一个功能的流程和通过流程化的思维呈现出一个产品功能的流程（交互）和写清楚需求就好了，其实这个思考并不深刻，同样的，在考虑扩展功能和在重构功能的时候，在流程里面塞东西（临时性和投机性），往往就是想到什么是什么（稍加论证和YY，就是扯淡），并且也会让功能逻辑和产品本身的逻辑和架构变得非常复杂和积重难返。
那么模块化思维就类似于软件开发的面向对象思想，本质上而言，面向对象的细节都是面向过程式（对应过程化思维）的，也就是在定义完软件架构即拥有良好可扩展的接口、代码结构、代码模块后，方法函数部分都是过程式的，只不过做了代码封装（模块集成）。同样的，模块化思维下的产品逻辑只考虑功能模块的扩展性、模块化、以及与其他模块和产品架构之间的关系，最终还是通过过程式的思维来呈现产品流程，但是这样的思维模型（模块化的统筹和过程式的展现）就让产品的组织和规划以及功能迭代和提出变得更有条理，结构也更清晰。
还是以知乎为例，用模块化的思维来下的产品逻辑来分析它的搜索模块和话题模块：
搜索模块：
首先我定义了一个搜索功能，将之模块化，就需要考虑两件事情：第一，它的入口放在哪里（单一入口或者多个入口），第二，搜索是结果导向的，那么结果分为几个维度？（还有考虑是不是有第三件事情 ^o^）：
1. 入口：按照知乎的定义，入口放置在了首界面的tab1顶端。
2. 维度分为内容和用户，其中内容包括话题和问题。可以看到，维度本身就是具备一定的扩展性（预留可扩展的接口），比如再增加其他结果维度或者将话题和问题分开展示，当然这个以整个产品的信息结果为基础，可扩展就意味着可优化，以及内容维度的粒度定义，诸如此类。然后在这些维度下结果的展形式：以item list的形式呈现，点击相应的item跳转到与之对应的item页。
我们发现，其实通过模块化的方式，从模块的起始到最末端，一定可以分解和导出具体可落地的设计、交互和功能。
那么很显然，可以得到：搜索功能需要一个搜索入口，进入搜索，按照定义的维度呈现搜索的结果，以及响应式搜索是为了更好的用户体验。（至于在展示搜索结果时提供的提问入口，这个与搜索模块无关，是在考虑与设计提问模块的时候，在考虑提供哪些提问入口的时候该考虑的事情。）
话题模块
1. 与问题相关：知乎的话题就类似于标签，叫法是什么不重要，每次在提问的时候可以打标签，即添加相关话题。很显然，话题可以聚合问题，即形成话题下的信息图谱，通过question list延伸到关联的回答，再延伸到关联用户，这样就可以形成：动态、最佳回答、问题list、最佳回答者（list）、动态（信息聚合变化）这些功能，以及话题因为有一系列的信息聚合，所以话题可以定义为可关注的，就有了关注功能，这里的信息聚合是可扩展的，同样的，延伸出来的功能同样就是可扩展的。
2. 话题本身（上图中没有画出）所包含的信息：名称、图片和描述，并且描述的维度是可以增加的（即可扩展的）。
3. 话题是枝叶结构（分类）：所以话题就存在父节点和子节点，即父话题和子话题，这里知乎提供了可以查看父话题。
4. 可扩展，比如与其他话题的关联，当看某一话题的时候推荐其他话题等等。
同样，这样的模块末端引导出的都是可实现的设计、交互和功能，并且通过流程化的方式组织成完整的功能流程。
很多初入产品行业的人只具从流程的角度去考虑一个功能的完整性，而模块化思维下的产品逻辑会让产品更加丰满，想事情更加清楚，一切皆可模块化，以模块的方式组织产品，考虑模块的完整性和模块的可扩展性，并且在模块的层面去思考，不断调整产品的最终呈现方式，即加减法（一个大前提，产品一定是要可落地的）。
我在此所说的仅仅是一个思路，或者仅仅是个片段，都只代表我的个人观点，望与各位切磋、交流。
