大平台业务分割后带来的碎片化业务痛点

大平台下的SOA, 其中很重要的就是业务切割, 最常见的, 产品信息和交易动作的分割,
带来了后端业务逻辑的清晰, 而反之, 则是前端成本的增加

其解决之道, 不在于技术, 也不在于产品策划, 而是在于产品活动策划和技术限制之博弈


案例一:搜索和价格2项维度带来的成本








搜索要快就要建立索引或快照, 而且搜索要兼顾的范围太多了, 淘宝, 天猫, 生鲜, 二手等
零售要销量, 要求价格体系灵活强大, 有6.1活动, 优惠券, 每人限购, 地区限购等
所以, 当搜索碰上零售就悲剧了


案例二:频道首页与商品实况脱节
已下架的商品, 还在频道首页出现





常规思路, 商品下架应该自动关联首页下架
但首页商品位子是固定的, 关联下架就造成缺口
下架商品和缺口相比, 明显前者比较好接受,
这算BUG乎?
如果是后备商品呢? 每个位子的递补又太难控制了



案例三:拿最近天猫的吃货节活动来说

其中30元吃货券很值得深究, 其中场景:
1. 5.12-5.19, 领券, 吃货券30元, 规划, 购买指定商品满168可以减30
2. 买指定商品, 可是, 我居然试了半天, 都找不到指定商品是什么

最后, 我在偶然的机会下, 乱点终于点到了指定商品

如图
第一步, 领取吃货优惠券




第二步, 我的优惠里想使用优惠券
从"我的优惠信息"和右侧的"我的资产"





一切好像很美好的样子, 但是, 我怎么知道这30元是适用的"部分商品"是什么啊, 点"立即使用", 直接跳天猫超市首页, 这叫我怎么使用!, 如图



最后, 在神游间, 终于找到这指定商品了, 如图



点击后, 效果"很不错"的样子, 如图


终于找到了: 猪肋排,  牛腩块, 牛腩块, 泪流满面啊

技术人员: 前端通过活动链接直接获取该活动优惠券的查询API

可是, 当我第二次再沿着左侧菜单进去的时候, 找不到了



之前的菜单定位





技术人员: 前端:页面使用以前的查询API, 后台没有给我也没办法
后端A: 这里是调"我的信息模块", 活动没有做同步, 我不可能为这时不时的活动天天改代码吧
后端B: 我草, 这活动coding的时候, 我的信息模块又没关注我, 又没提供接口给我倒注数据,
架构师: MD, 当初设计的时候, 谁知道你要开在这里同步数据啊, 那会根本连"天猫生鲜"都没有好不
产品经理: !@T%@#$@$%Y#Q, 改一下要多久
架构师: 改这结构, 涉及到数据同步, 数据库表, 旧记录添加字段, 默认值, 淘宝和天猫不在一个模块, 还
产品经理: TMD, 不就添加个优惠券啊, 基于这么蛋疼么
架构师: 啊, 还要查下还有什么模块调用这接口了, 都要考虑下, 要XXX(不少于1周)
产品经理: !@%#$!#$^@, 让用户找去吧, 反正是优惠券, 找到算到赚, 找不到就拉倒, 反正用户也没亏

以上, 纯属YY

解决办法: 在这种优惠业务还成熟之前, 去改架构是很不划算的, 成本太高
所以, 比较快速敏捷的解决办法是: 从产品上解决, 在领券后, 引导用户跳到此券指定商品的页面
但也许这又涉及到另一个"架构"调整也不定,



不管如果, SOA在分化业务的同时, 也增加了通讯成本, 对一个平台(产品)来说, SOA不是万能药, 还是要在自身下功夫: 架构并不仅止于技术, 产品业务逻辑(产品架构)清晰