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

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

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


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

[img]http://dl2.iteye.com/upload/attachment/0117/7159/c856e5a4-d0a4-3d1b-bc87-f6f8c447c774.png[/img]

[img]http://dl2.iteye.com/upload/attachment/0117/7161/e444b9a7-9190-3208-b75f-c4fa42b0e98e.png[/img]

[img]http://dl2.iteye.com/upload/attachment/0117/7165/82349b8c-cbe2-3832-bf72-f03637b4f32c.png[/img]

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

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

[img]http://dl2.iteye.com/upload/attachment/0117/7414/45e818e7-418e-3e80-b488-1b61791073a3.png[/img]

[img]http://dl2.iteye.com/upload/attachment/0117/7416/36a291ff-c9aa-39c7-99b0-b4e543cbdb6f.png[/img]

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


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

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

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

如图
第一步, 领取吃货优惠券
[img]http://dl2.iteye.com/upload/attachment/0117/5111/db78371f-1882-3b9c-9eef-e37bb308cdc2.png[/img]

[img]http://dl2.iteye.com/upload/attachment/0117/5115/029420c8-3202-3918-bdd8-fc18ce7afdcc.png[/img]

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

[img]http://dl2.iteye.com/upload/attachment/0117/5117/24dbba3e-cb91-301a-89f2-8cc6b289db50.png[/img]

[img]http://dl2.iteye.com/upload/attachment/0117/5119/67325a74-295a-3647-ab1a-3be8cca0a574.png[/img]

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

[img]http://dl2.iteye.com/upload/attachment/0117/5121/0bd610a4-cbca-30df-9643-4b1b762c6f54.png[/img]

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

[img]http://dl2.iteye.com/upload/attachment/0117/5123/83202a59-3367-3d24-b8df-3e17e39b2508.png[/img]

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

[img]http://dl2.iteye.com/upload/attachment/0117/5125/3ee05c2c-e8f9-335d-aaf3-29ab5350dd17.png[/img]
终于找到了: 猪肋排, 牛腩块, 牛腩块, 泪流满面啊

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

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

[img]http://dl2.iteye.com/upload/attachment/0117/5127/1e3277d1-7b8c-3431-ac59-4b3ff3ce6555.png[/img]

之前的菜单定位

[img]http://dl2.iteye.com/upload/attachment/0117/5132/b9bdc573-e052-3dff-a006-9092124f8869.png[/img]


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

以上, 纯属YY

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

[/i][/b]

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