1
回答
一个O2O后端架构问题咨询
科大讯飞通用文字识别100000次/天免费使用。立即申请   

一个后端架构问题咨询

业务: O2O,采购方通过App向供应商申请供货,供应商审核通过后 , 采购方可在App上进入该供货商的店铺中进行下单。

后端 仅负责提供Rest Api,前端调用后端提供的接口来完成页面逻辑展示。后端使用了Spring boot+Data Jpa来开发,按系统拆分工程, App(采购方注册,关联供应商,下单等),供应商后台(审核采购方,管理商品,查看订单等),平台自己的后台(管理供应商和采购方,统计查询等)。

有些接口可以共用,如查询采购方详情,省市区Api等, 每个工程都能用到, 因为一开始先开发的App, 所以刚刚提到的几个接口都是在App工程中, 所以开发后面供应商管理后台时前端需调用App工程中的接口,最后开发平台后台系统时,可能需要调用三个工程中的接口。针对这种情况是每个工程中冗余呢? 还是将可以共用的接口抽取出来呢?

现在突然觉得若后端仅负责提供Rest Api的话, 不关心业务的话, 似乎没有必要按系统拆分工程了, 直接提供采购方,供应商,商品,订单等的CRUD Rest Api即可。

不知道针对这种场景的后端架构设计大家怎么看?可有什么好的实践推荐?

<无标签>
举报
zgw06629
发帖于3年前 1回/158阅
共有1个答案 最后回答: 3年前

只要mc层,各自的api在c,公共数据查询在m,结构清晰,也方便修改。没明白你的疑惑

--- 共有 2 条评论 ---
xper@zgw06629 首先你要认识到你的功能是一体的,你不能通过保证某个功能正常为基准,所以你可以把主要的功能就是操作数据库的逻辑放在一起,控制给用户的直接再次封装,这样维护就主要是给客户这部分,要是担心主服务器出问题就备份一台服务器,这样你的功能,就是调用外部的也不担心,配置统一,还是在给客户能读的地址里实现逻辑,重点还是把公共操作数据库集合起来。比如通过id查订单功能就放在数据层在重要的数据库上,而如何封装格... 3年前 回复
zgw06629我的担心是,拆开来互相调用的场景,使得部署很麻烦。如每个工程都必须随时在线,不能因为平台后台给自己人用的就单机部署以及随意更新。以及接口管理如App中还依赖了其他哪些工程的接口,能不能直观的展示出来。 3年前 回复
顶部