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