系统架构_零售系统架构图

对零售系统分析了下&＃xff0c;然后设计了个架构图&＃xff0c;基本有了这个架构图&＃xff0c;剩下就是对具体页面功能逻辑进行设计而已。在设计这个架构图的过程&＃xff0c;有一些想法

1、业务是基于网上一个文章“新零售-从业务到产品”有兴趣可以看看&＃xff0c;文章上面也有一套架构图。不过看了文章及架构&＃xff0c;是基于自身业务逻辑来设计&＃xff0c;而不是基于通用saas设计&＃xff0c;所以抽离了下。

2、基于saas设计的一些考虑点&＃xff1a;

A、要考虑客户可能没有WMS、TMS、ERP等系统情况&＃xff0c;说白了&＃xff0c;就是要考虑完全没有外部系统的情况下&＃xff0c;单靠这套系统就能撑起来所有业务。一开始是没有增加“采购”、“仓库”、“物流”这些模块&＃xff0c;但是考虑到这种情景下&＃xff0c;的确需要添加这些模块&＃xff0c;但是只需要最核心的功能即可

B、多账号中心&＃xff1a;saas系统是多租户&＃xff0c;每个租户的权限、数据都是独立。所以设计这套系统的时候&＃xff0c;需要增加一个“多账号中心”&＃xff0c;目的是独立授权。

C、模块之间都得提供行业标准接口&＃xff0c;不过这种就是后端技术的了&＃xff0c;在功能架构里面&＃xff0c;其实比较难体现。主要是考虑这个系统肯定会存在只要某几个功能模块&＃xff0c;其他功能服务&＃xff0c;通过第三方系统满足的情况&＃xff0c;这种情况下要做的只是提供行业标准的接口&＃xff0c;然后让他们对接就好了。

3、模块大小划分问题&＃xff1a;这个~~自身经验问题&＃xff0c;所以模块划分也许存在不合理情况。不过对于saas系统来说&＃xff0c;当系统复杂度去到一定程度&＃xff0c;才需要拆分代码。在此之前有个大概范围划分就好。原因是很难完全一下子将业务梳理清楚&＃xff0c;其次业务不停在发生变化&＃xff0c;新业务不断产生&＃xff0c;也许大模块下再拆分子模块&＃xff0c;这种是很正常的。&＃xff08;试想下&＃xff0c;一个CRM也可以做到非常非常复杂&＃xff0c;非常非常精细&＃xff0c;但是对于零售系统来说&＃xff0c;起码现在这些模块设计可以满足80%的需求。&＃xff09;

因为没在这个行业从事过&＃xff0c;分析是基于空想及一些文章&＃xff0c;所以肯定存在不合理或者有场景不满足。但是saas系统本身就是不断成长&＃xff0c;不断发展的系统&＃xff0c;今天你看到的是这样&＃xff0c;明天可能就会增加更多的服务。

刚入行的时候接触的是软件外包&＃xff0c;软件外包转型产品&＃xff0c;如果走saas之路&＃xff0c;最缺乏的是对这个行业的深入了解业务及抽象设计能力&＃xff0c;设计出来的东西能够通用。