抽象|设计产品架构的基本方法( 三 )

这里再次用了解耦这个词，为什么会反复用到它，根本性原因就是考虑业务的扩展性，也是考虑整个平台的伸缩性。不要把各个功能模块过于紧密的耦合，导致任何些微的改动，都必须大动干戈。
最蹩脚的设计，就是所有功能只看到一个业务线，所有人都在忙活，但没有人搞得清楚边界。
还有一种糟糕的局面就是，完全的各自为政，没有协同，没有次序
这两种情况我都见过，带来的后果除了平台的效率低以外，也是资源的浪费，更是阻塞了团队的上升空间。——阻塞整个团队获得成就的通道，也阻碍团队能力的提升。
3. 集中的数据处理层相比较于“用户层”，是所有人都直观可见的是，所有人都知道有一个“数据库”，甭管知不知道数据是什么，有哪些，要怎么用，它就相当于我们的钱袋子，装得有东西肯定就比没东西更好。
再要怎么摆弄摆弄，无法是钱票子装得多点，容易数一点的问题。
所以，这一层处理的问题就是，产品的数据从哪里，沉淀到哪里去。实际上，稍微深入一点的问题就是数据如何高效的存储，如何快速的被调用。
比如今日头条的推荐算法，就是根据用户在使用（用户层的行为）过程中产生的数据，来绘制这个用户的习惯偏好，采用一种恰当的规则来推荐相关的内容，从而使得这个用户更多的停留在产品上。
然后在此基础上催生更多的商业可能性。
让我们在回到案例中的O2O项目。

文章插图
我们用一个“用户故事”来描述当时我们需要解决的用户问题：
“张三新买的冰箱出现了故障，他找到当时的回执单申报了一次售后服务，要求在周六上午处理完冰箱的故障”。
从这个描述过程中，我们就能知道3个关键信息：

文章插图
用户信息：
要有一个方便的界面协助用户申报服务，怎么能让用户在申报服务的时候把资料问题录入正确，有没有办法在用户打开这个界面就直接解决问题，有没有一个FAQ供用户查阅；
业务信息：
后台要处理用户的服务请求（申报的售后服务），要安排一个擅长处理这个故障的工程师上门服务（业务技能要匹配，不能派一个不懂冰箱的工程师处理这个问题），时间是周六（资源要调配，距离太远不合适，时间冲突不合适等）；
数据信息：
上次的订单是怎么找到的，这个用户是不是在服务期内，是不是要额外收费，费用是多少。这次处理完的订单怎么和上次的订单相关联等等。
按照这种逻辑，就能清晰的勾勒出，在处理用户的服务请求所需要完成的系列动作，整个平台的数据和信息是如何进行流转，以及为了支持整个平台需要开发的产品功能有哪些。
当然，单凭这一个“用户故事”就能绘制一个大概的业务轮廓。
这是一种最简单的分层机制，我们可以快速的得到一个初步的产品框架，当然一定存在不少边界不清晰，分层不明确的问题，我们还需要根据不同信息层级的边界、同一层级内模块和模块的边界。
下一步，则是针对具体的业务展开规划。
三、抽象与解耦在前述的”分层“逻辑中，在各个业务层级中，我用了很多“小豆腐块”表示具体的功能。我想你现在的疑问应该是，这些小豆腐块是如何被界定，它们的依据又是什么呢？
比如架构中有“接单”、“履约”、“回单”、“订单列表”，为什么没有登录，修改密码这些基础功能，是因为这个产品不需要这些功能吗？