对零售系统分析了下,然后设计了个架构图,基本有了这个架构图,剩下就是对具体页面功能逻辑进行设计而已。在设计这个架构图的过程,有一些想法
1、业务是基于网上一个文章“新零售-从业务到产品”有兴趣可以看看,文章上面也有一套架构图。不过看了文章及架构,是基于自身业务逻辑来设计,而不是基于通用saas设计,所以抽离了下。
2、基于saas设计的一些考虑点:
A、要考虑客户可能没有WMS、TMS、ERP等系统情况,说白了,就是要考虑完全没有外部系统的情况下,单靠这套系统就能撑起来所有业务。一开始是没有增加“采购”、“仓库”、“物流”这些模块,但是考虑到这种情景下,的确需要添加这些模块,但是只需要最核心的功能即可
B、多账号中心:saas系统是多租户,每个租户的权限、数据都是独立。所以设计这套系统的时候,需要增加一个“多账号中心”,目的是独立授权。
C、模块之间都得提供行业标准接口,不过这种就是后端技术的了,在功能架构里面,其实比较难体现。主要是考虑这个系统肯定会存在只要某几个功能模块,其他功能服务,通过第三方系统满足的情况,这种情况下要做的只是提供行业标准的接口,然后让他们对接就好了。
3、模块大小划分问题:这个~~自身经验问题,所以模块划分也许存在不合理情况。不过对于saas系统来说,当系统复杂度去到一定程度,才需要拆分代码。在此之前有个大概范围划分就好。原因是很难完全一下子将业务梳理清楚,其次业务不停在发生变化,新业务不断产生,也许大模块下再拆分子模块,这种是很正常的。(试想下,一个CRM也可以做到非常非常复杂,非常非常精细,但是对于零售系统来说,起码现在这些模块设计可以满足80%的需求。)
因为没在这个行业从事过,分析是基于空想及一些文章,所以肯定存在不合理或者有场景不满足。但是saas系统本身就是不断成长,不断发展的系统,今天你看到的是这样,明天可能就会增加更多的服务。
刚入行的时候接触的是软件外包,软件外包转型产品,如果走saas之路,最缺乏的是对这个行业的深入了解业务及抽象设计能力,设计出来的东西能够通用。
原文地址:https://www.cnblogs.com/summersolstice/p/11428390.html