这个系列文章既是对自己差不多近10年的工作总结，也是给给一些初级的电商的后端系统的一些搭建的建议。
这个系列的文章不涉及到很深的技术知识，也不是支付公司的系统介绍（任何一家支付公司均不可能从这么简单的做起）支持的阅读对象应该是系统产品经理或者项目经理之类的人物，各位技术大牛不要瞎喷
首先，我们默认大家知道什么是支付，什么是账户。
一个最小原子化的系统应该如下所示：
根据上图可知，只需要商品展示界面，支付展示界面（收货信息录入，支付信息录入或者微信，支付宝跳转界面），后台系统只需要商品数据库，和支付流水数据库即可。
此系统仅支持账户匿名购买，所有的信息均保存在支付流水里面，在运营界面中提取出来展示给人工即可。与支付渠道（支付公司，银行）对接仅对接扣款，甚至对账都不需要，直接去支付渠道提供的运营页面人工与自己的运营页面中的展示数据比较。个人可以没有任何个人资料和账户信息。
当然，如果是各种黄赌毒网站的话，甚至都不需要和支付渠道相连（业务范围无法准入），直接填写收货信息下单结束，后续的付款由运营人员根据下单的信息去人工联系。
下一步，一点一点的东西往上加。首先你得先收集用户信息对吧，那么你在前端需要增加注册登录页面，后台系统增加个人资料存储库，你希望对方能够先充值，再支付，这样就可以有资金池的沉淀（貌似不允许？不过好像很多网站都这么干，各种转运公司啊，或者各种提供服务的网站），如果不能用现金余额来表示（合规问题？），那么你可能需要换算成虚拟货币，或者积分，之类的东西？那么后台系统需要增加一个账户系统来分别存储这些数据
下一步，你会发现数据量大了（生意好了？）的时候，可能有些客户有奇葩要求了，要求有先下单，等有钱了再来付款，或者合并订单付款，或者使用积分，红包，抵扣券付款之类的事情，这个时候，只有一条支付流水可能就不够用了。这个时候，支付模块需要单独独立出来，前面再增加一个商品订单模块（这个时候还不能称为系统），这样有了商品订单流水，与支付流水相拆开，那么就能够支持多个商品合并付款（多个商户订单流水对应一个支付订单流水），以及使用多渠道（积分，红包加现金）付款（一个商户订单或者多个商户订单，对应多条支付流水）的情况
OK，至此，一个简单的电商网站的小模型就出来了，我在后续的文章中会着重讲解支付系统，账户系统，以及清结算系统这些东西是如何出来的，但是因为支付这个行为一定是与买东西的息息相关的，所以我在后续谈到支付，账户，清结算这些系统的时候，均会带到一点前面的商品，商户之类的概念。不过对于用户运营，商品，客户的管理啥的，我就不懂了，那么也不会太说到，所以么，呵呵，你懂就行，别来喷我~
