架构|设计产品架构的基本方法( 二 )

所以，整个产品的架构设计，也就是基于这一个连锁反应进行的业务层和逻辑层的解耦分拆，系统性的规划整个O2O平台的前后端如何高效的协同。
同时，基于这一个基本规则，我们再考虑平台的未来业务发展，甚至我们还需要考虑到未来三五年的业务容量会达到什么量级，由此需要采用怎样的技术设计和资源配置（云端服务资源）。
由此可见，产品架构设计，首先就是一个分层设计的过程。

文章插图
常来说，最容易实现的产品层级结构就是三层，即用户层、功能层和数据层，这种层级关系即可完整的实现前、后台关系的业务系统：
1. 统一的用户感知层解决的是用户触达的问题，考虑在何种场景下通过何种方式触达用户，最表层的业务体验，也就是我们常说的“用户体验”，包括界面，布局，配色等直观可见的每一个产品页面。
在这个层面，我们考虑的是如何更好的表达我们想要表达的业务元素，如何能够更吸引用户的注意力和停留决策，它在一定程度上决定了用户是否会立即卸载，或者是带着好奇之心在有效的引导下探索产品。
这是产品经理的必修课，因为它能直观的让人直接评断产品，最常见的说辞就是“丑爆了”，而且是任何一个产品都会遭受到这一批评，哪怕你是微信也毫不例外。
但真正决定体验的，并不是这一层，但又无可奈何必须面对的现实。所谓人靠衣装吧，一个打扮时髦的美女你甚至都会觉得她特别让你感觉亲密，甚至你会直觉认为她根本就是一个好人，一个让你喜欢的人。
2. 解耦的业务功能层多少产品经理实际在这个层级就开始陷入迷糊状态，根本不知道甚至没有意识到“功能”的分解和层次设计，在他们眼里，任何产品都只需要一个界面+一个数据库，即可愉快的完成所有业务。
也是因为这种主观的判断，让多少人总是认为这个东西很简单，那个东西很容易，别人都可以做出来，你为什么明天还不能上线，以及谁谁谁又做了这么一个功能，我们明天也要做一个。
诸如此类的根本原因就是只见树木不见森林。
这一种粗浅的认识，也带来大量的产品被粗制滥造，胡乱承诺，最后不得不草草收场，因为这些产品从一个开始就没有被真正的理解和设计，而是想当然的认为“我们只差一个程序员，明天就可以上线”。
对这一层级的认知不足，会让我们陷入一种奇怪的局面。
“一个妈妈生一个孩子要10个月，10个妈妈生一个孩子只需要一个月”。
“业务功能”的解耦，本质是解决产品的核心功能的设计问题，包括如何高效的完成业务功能，如何与用户层进行交互，如何与外部系统进行数据通信等一系列复杂的业务处理。
很多人无法理解，某个功能为什么要这么设计，为什么不能那样设计，就是无法真正理解这一层的设计，从而加剧整个产品在最开始阶段就限定了它的可能性。
这是“重构”的原罪。
这里再次用了解耦这个词，为什么会反复用到它，根本性原因就是考虑业务的扩展性，也是考虑整个平台的伸缩性。不要把各个功能模块过于紧密的耦合，导致任何些微的改动，都必须大动干戈。
最蹩脚的设计，就是所有功能只看到一个业务线，所有人都在忙活，但没有人搞得清楚边界。
还有一种糟糕的局面就是，完全的各自为政，没有协同，没有次序
这两种情况我都见过，带来的后果除了平台的效率低以外，也是资源的浪费，更是阻塞了团队的上升空间。——阻塞整个团队获得成就的通道，也阻碍团队能力的提升。
3. 集中的数据处理层相比较于“用户层”，是所有人都直观可见的是，所有人都知道有一个“数据库”，甭管知不知道数据是什么，有哪些，要怎么用，它就相当于我们的钱袋子，装得有东西肯定就比没东西更好。
再要怎么摆弄摆弄，无法是钱票子装得多点，容易数一点的问题。
所以，这一层处理的问题就是，产品的数据从哪里，沉淀到哪里去。实际上，稍微深入一点的问题就是数据如何高效的存储，如何快速的被调用。
比如今日头条的推荐算法，就是根据用户在使用（用户层的行为）过程中产生的数据，来绘制这个用户的习惯偏好，采用一种恰当的规则来推荐相关的内容，从而使得这个用户更多的停留在产品上。
然后在此基础上催生更多的商业可能性。
让我们在回到案例中的O2O项目。