零售系统架构图

对零售系统剖析了下，随后设计了个架构图，基本上拥有这一架构图，剩余便是对实际网页页面作用逻辑性开展设计罢了。在设计这一架构图的全过程，有一些念头

1、业务是根据在网上一个文章内容“新零售-从业务到商品”有感兴趣可以看一下，文章内容上边也有一套架构图。但是看过文章内容及构架，是根据本身业务逻辑性来设计，而不是根据通用性saas设计，因此抽身了下。

2、根据saas设计的一些考虑到点：

A、要考虑顾客很有可能沒有WMS、TMS、ERP等系统状况，简言之，便是要考虑到彻底沒有外界系统的情形下，只靠这套系统就能挺起来全部业务。一开始是没提升“购置”、“库房”、“货运物流”这种模块，可是充分考虑这类场景下，确实必须加上这种模块，可是只必须最主要的作用就可以

B、多账号中心：saas系统是多租户，每一个租赁户的管理权限、数据信息全是单独。因此设计这套系统的情况下，必须提高一个“多账号中心”，目的是单独受权。

C、模块中间都得给予领域通信接口，但是这类便是后面技术性的了，在作用构架里边，实际上非常难反映。主要是考虑到这一系统毫无疑问会存有只需某好多个作用模块，别的作用服务项目，根据第三方系统达到的状况，这样的事情需要做的仅仅给予国家标准的插口，随后让他俩连接就好了。

3、模块尺寸区划问题：这一~~本身工作经验问题，因此模块区划或许存有不科学状况。但是针对saas系统而言，当系统复杂性去到一定水平，才必须分拆编码。在这之前有一个大致范畴区划就行。缘故是难以彻底一下子将业务整理清晰，次之业务不断在产生变化，新业务持续造成，或许大模块下再拆分子结构模块，这类是很常规的。（设想下，一个CRM还可以保证十分比较复杂，非常非常细致，可是针对零售系统而言，至少如今这种模块设计可以达到80%的要求。）

由于没在这个领域从业过，剖析是根据妄想及一些文章内容，因此毫无疑问存有不科学或是有情景不符合。可是saas系统自身是持续发展，飞速发展的系统，今日你见到的是那样，明日也许便会提升大量的服务项目。

刚入门的情况下触碰的是软件外包，软件外包转型发展商品，假如走saas之途，最欠缺的是对这一领域的深入了解业务及抽象化设计工作能力，设计出去的物品可以通用性。