什么是系统做深和系统做宽

系统做宽

我们一般做业务需求，都会做一期二期迭代。迭代后，能支持的业务场景越来越多也就是系统做宽

系统做深

我们在做根据业务需求做方案设计的时候，应当考虑这个业务场景使用的一些能力是否是定制化的，如果不是如何抽象化成业务中台的能力。能够给将来各个场景的业务服务或者业务做支撑。

案例一巡店需求

需求

巡店需求,业务需求本身是，巡检员到门店进行巡检，如果巡检不通过则要求门店进行整改，涉及巡检表(巡检规范定义、门店、物流、运维检查规范都不一样)、巡检记录(巡检员对基于巡检表的规范进行检查的记录)、整改单(下发整改单)

为了避免巡检员没到现场就填写巡检记录,需要巡检员到达门店进行签到和签退。

做深思维抽象

签到

是否可以设计为一个通用的能力、支持未来各个业务场景。巡检签到、积分获取签到、或者促销活动连续签到x天送x商品。

巡店

业务本身是指定规范，对应角色做检查，检查不通过下发整改。那么业务领域是否应该设计成巡检，本期：门店巡检。后期业务支持:仓库巡检、物流巡检、运维巡检，其他各种职能部门业务巡检。

案例二物流发货和门店退货需求

需求

1.物流中心给门店进行发货->门店进行收货

2.门店给物流中心进行退货->物流中心进行收货

做深的思维

不管是物流给门店发还是门店给物流进行退。本质都是运输，如果是运输，那么发货方和收货都可以是任意一种形态，而不是局限于需求本身

物流中心发门店

门店发中心物流

物流中心发中心物流

门店发门店

xx-》xx

所以不局限于需求本身设计，业务域应该是运输。 发货方收货方 不仅限于门店和物流 ，从数据结构上应该设计 成：发货方、发货方类型(物流？门店？)、收货方、收货方类型(物流?门店？)