后台办理体系又称 B 端多商店产品。与我们直接接触到的 C 端多商店产品互联网多商店产品不同的是，B 端多商店产品更像是冰山下的一角，承载了大量的功用，资料和事务流程。做一款多商店产品、需求明晰多商店产品定位，即多商店产品的多用户是谁、能满意这部分多用户哪些需求，解决哪些问题。具体 wordpress 站群总结如下：
一、事务流程是魂灵
B 端多商店产品更靠近事务。熟悉事务是做好 B 端多商店产品的前提。以电商商家体系为例，多商店产品来历有两个维度、一种是自营、一种是商家入驻供给。商家体系需求支撑商家把多商店产品卖出去，而且卖的很好。但这简略需求的背面，包括了商家需求进行入驻——然后释出多商店产品——办理订单——处理售后——货款结算——提取货款这几大杂乱流程。如果把后台办理体系看作是人。事务流程就像魂灵一样，它决议了多商店产品的形态。
二、功用模组低耦合
依据事务流程衍生出：商家办理、多商店产品办理、订单办理、物流售后、货款结算、账户办理几大基本功用模组。每个模组又包括多个选单功用。商家办理：包括商家注册登陆、公司资讯办理、资质认证、交纳保证金。多商店产品办理：办理多商店产品品牌类目、释出多商店产品、多商店产品上架、多商店产品下架、多商店产品库房。订单办理：订单检视、反常订单处理、退换货单据办理。物流售后：物流配送设定、发货办理。货款结算：结算办理、结算明细、赔付单据办理、运费结算办理。账户办理：保证金体系、货款查询、账户额度查询。
有了详细模组后，我们就能细化详细选单功用。跟著事务的变迁增加、规划增加、一些功用模组又会被剥离成为一个个独立的体系，因而，功用模组规划时需求留意低耦合、在重构之日，能较好的搬迁。后台多商店产品许多都需求了解乃至懂技能、由于后台体系规划、我们需求细化每个栏位、了解资料库、表结构。
三、资料流向是血液
一个多商店产品有两种资料：输入出资料，资料流向指体系输入资料的去向、输出资料的来历。资料的活动使得多商店产品变得有生命力。后台体系并不是单一的存在、一个商家体系与之互动的有：招商办理体系、多商店产品体系、订单体系、付出体系、财政结算体系、物流体系、 BI 体系、站群营销体系、广告体系、引荐体系、音讯中心…
在多商店产品规划时、需求明晰的知道，每个功用模组与之互动的体系，每个单一资料的去向，流转，牵涉到相关体系的影响。这样才干躲避风险。一起把控多商店产品的拓展性，延伸性。
规划后台体系还需留意以下几点：体系易用好懂，杰出易用的体系、能大大提高相关作业人员、同事的功率、直接节约时刻本钱；功用模组低耦合，规划后台多商店产品就是做架构，互联网多商店产品增加非常快，迭代频繁，多用户增加都是数万计的，也许三五个月，现有的体系已不满意当时的事务，而杰出的模组区分、低耦合，不管是在迭代重构之日，还是资料搬迁，都会起到极大的效果。