设计思路之系统做深能力的思维方式
什么是系统做深和系统做宽
系统做宽
我们一般做业务需求,都会做一期二期迭代。迭代后,能支持的业务场景越来越多也就是系统做宽
系统做深
我们在做根据业务需求做方案设计的时候,应当考虑这个业务场景使用的一些能力是否是定制化的,如果不是如何抽象化成业务中台的能力。能够给将来各个场景的业务服务或者业务做支撑。
案例一巡店需求
需求
巡店需求,业务需求本身是,巡检员到门店进行巡检,如果巡检不通过则要求门店进行整改,涉及巡检表(巡检规范定义、门店、物流、运维检查规范都不一样)、巡检记录(巡检员对基于巡检表的规范进行检查的记录)、整改单(下发整改单)
为了避免巡检员没到现场就填写巡检记录,需要巡检员到达门店进行签到和签退。
做深思维抽象
签到
是否可以设计为一个通用的能力、支持未来各个业务场景。巡检签到、积分获取签到、或者促销活动连续签到x天送x商品。
巡店
业务本身是指定规范,对应角色做检查,检查不通过下发整改。那么业务领域是否应该设计成巡检,本期:门店巡检。后期业务支持:仓库巡检、物流巡检、运维巡检,其他各种职能部门业务巡检。
案例二物流发货和门店退货需求
需求
1.物流中心给门店进行发货->门店进行收货
2.门店给物流中心进行退货->物流中心进行收货
做深的思维
不管是物流给门店发还是门店给物流进行退。本质都是运输,如果是运输,那么发货方和收货都可以是任意一种形态,而不是局限于需求本身
物流中心发门店
门店发中心物流
物流中心发中心物流
门店发门店
xx-》xx
所以不局限于需求本身设计,业务域应该是运输。 发货方收货方 不仅限于门店和物流 ,从数据结构上应该设计 成:发货方、发货方类型(物流?门店?)、收货方、收货方类型(物流?门店?)
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 全程不用写代码,我用AI程序员写了一个飞机大战
· DeepSeek 开源周回顾「GitHub 热点速览」
· 记一次.NET内存居高不下排查解决与启示
· 物流快递公司核心技术能力-地址解析分单基础技术分享
· .NET 10首个预览版发布:重大改进与新特性概览!
2022-10-18 计算2个时间相差多少天多少分钟多少秒