上一章，大致说了一下项目所要做的东西，以及对于框架选择的原因。在这里继续接下去说项目是如何一步一步的开发的。
首先需要说一点的就是，如果一个项目存粹的是为了自己公司去盈利或者为了以后发展，不是为了拿来拉融资的，可以很肯定的说，前期基本都是在砸钱，基本半年内不用想着有收入，如果一开始就想着赚钱，那极大有可能导致崩盘。说白了一句就是：沉不住气。
先说一下项目
整个项目的构架可以分为3大模块，商家端，小程序，AI名片后台。由于需要考虑到版本上线以后，新版本的开发，因此需要创建两个项目，一个是beta,一个是master项目，若是版本上线以后需要BUG修改，还需要建立一个bug分支。
因为这个项目我是打算从一开始就想着以后如何去更好的发展的，所以有一点是千万不能忽视的，那就是系统日志的功能，针对于系统日志的功能，用的可以是文件存储，当然这种形式是可以的，但是一旦数据量大，可能会就导致查询的时候反省慢，当然也可以吧数据放数据库，但是数据库的弱点很明显，他的读取效率真的不高，而且高并发的问题也是他的一个弊病，如果用RDS的话，先不说他处理高并发的能力，他的价格就有点望洋兴叹。综上所述，可以替代的只有mongodb，他的存取效率也快，虽然比不上redis,但是数据库和他比肯定比不上的。因此作为日志和数据的统计，我基本就放在mongo里面，这样读取也方面。
接着就是说到接口安全性的问题了，在这边我用是rsa加密和rsa解密来作为安全验证，用户在登录的时候，通过公钥生成一个token,然后通过每次接口调用利用token来做安全解析。其次对于请求接口获取参数的时候，也进行参数的验证，为了防止恶意数据或者额外数据的进去。
之前做过一些项目，也看过一些代码，发现一个点就是针对于，分类这块很多人使用的都是递归的方式去实现，这种方式可以很明确的说，这种方式是最耗数据库 ，同时如果需要实现无限极分类，还用这种方式，直接会导致脑子短路，全程懵逼，一旦注入的商家多了，数据量大了，那频繁的读取数据库，最终导致的就是，调用这个分类接口，最后耗时要N久N久。在这里可以友情推荐一种方式，距离逻辑自己可以自己考虑，就以A级为一分类，表中设置一个字段，cat_num_id 可以设置为00001 那他的二级分类可以为00001,00001 如果在有个A级的下级分类可以为00001,00002。以此类推，可以无限极分类，当然查询的时候，为了保证分类是有序化的，可以直接用cat_num_id 进行排序，最后得到的数据就是按规则上下级排列的数据。在这大致说一下思路，具体的可以慢慢摸索。
在后台中着重需要说一下的就是一个系统统计的功能，因为这块功能关乎于订单系统，包括用户浏览，用户注册，以及活动的统计，设置于说是未来如果项目发展好，考虑到大数据的分析都有着重要的作用，但是由于这块内容的数据量太过庞大，因此可以把统计数据放在mongo里面，这样以便于减少数据库的压力。
其余的一些商家后来的商品增删改查，以及订单后期处理，活动的设置，同款商品的分类就不具体细说了，因为这个人都有自己的思维逻辑，蛋归根一点就是在实现功能的前提下如何更优化简便的去实现功能，从而来减少商家的工作量。
