整体架构设计

存储层

领域层

聚合层

业务线、开放平台

终端

存储模型设计

会员模块

1、会员注册信息表

id、注册手机号、昵称、会员号

2、会员基础信息表

id，会员编号，注册时间、实名认证标识... ...

3、验证码发送记录信息表

id，手机号、验证码、失效时间、验证码类型、发送状态

能力设计

1、验证手机号是否已经注册会员

2、新用户注册会员

3、生成和发送验证码

4、校验验证码正确性

详细设计

1、会员注册

1.1、手机号注册前，要验证手机号是否已经在平台注册会员
方案1 ： 通过比对注册手机号和已经注册的手机号，直接在数据库中查询，匹配上则表示手机号已经注册了会员，违背业务规范，一个手机号只能注册一个会员。
方案2 ： 当数据量达到百万级别，不能再用手机号和已经注册的手机号查询比对的方案，而是把注册手机号单独记录，采用二进制占位符的方式。减少存储量。和提升性能。

1.2、 会员注册的信息，尽可能小，基本上是手机号、昵称即可，另外要使用手机号+验证码，防止手机号被他人乱用。
手机号+验证码处理方案： 如果新客注册，请求量不是特别大的时候，可以直接采用数据库存储和校验，验证码发送记录，记录到数据库，比较验证码时候，可以从数据库中查询出来比较。
如果当项目运行时候，遇到响应慢，而且瓶颈正好在DB的IO开销时候，可以把验证码信息，加一层缓存，优先从缓存中获取（尽快缓存失效时间控制在1min+，防止击穿和穿透）。
验证是非常重要的过程事件，但是已经验证通过的，验证码记录则是无关紧要的数据，可以定期清除，同时要限制同一个手机号一天或者，短时间发送验证码的数量，基于平台或者具体业务，做个阈值，且可以动态调整，推荐是把阈值的设置放在架构的配置中心模块。

1.3、会员实名认证
方案一： 姓名、身份证号、银行卡的方式。（该方案比较传统，移动终端时代，基本不采用该方式）
方案二：姓名、身份证、人像识别。（当前比较常用的方案）
方案三： 借助其他已有实名名认证的平台，如果微信，支付宝等。授权和绑定该账号，间接完成认证。