重构 用户管理架构设计
今天给大家分享的是：用户管理模块
或者说用户管理子系统如何设计，包括如何抽象以及相关的存储。
大部分的应用中都会有用户的概念，除非你的网站全部是匿名访问，不保存用户任何信息。其实这也是不好的，因为你的网站如果没有用户的概念，没有设计用户模块，就很难收集用户信息及用户行为，也就很难有数据来分析用户的喜好，也就少了一条给用户提供更好服务的途径。
现在是 web2.0 的时代，甚至是 web3.0，用户越来越在意网站给自己带来的内容，显示的内容是否合适自己，而且用户很想参与网站的内容构建，想要对自己构建的内容进行聚合、管理。
说了这么多，就是要说明用户管理模块很重要，是个应用就应该考虑，而且还是重中之重。
先来看一下用户信息都包含哪些内容。
常见的内容包括：登录账号，登录密码，电子邮箱，个人网址，手机，QQ，简介，标签等等。
用户还可能包括企业用户，就会有：企业名称，企业注册号，企业工商号，企业营业执照号，法人，联系人，联系人职务等等企业信息。
如果是涉及到金钱往来的应用，例如：电商网站。肯定还会有银行账户信息：开户银行名称，开户名称，开户账号等。
用户会有很多的类型。
有的是个人，有的是企业。
有的有银行账户信息，有的没有银行账户信息，现在没有的，以后可能会有。
在用户认证方面现在可能是 username/password，以后可能需要支持第三方认证（例如：微博，twitter，qq），还可能需要 SSO。
刚吊起胃口就未完待续了，这个分割点，嗯，很到位。。。
不过这个貌似讨论用户信息怎么划分怎么存放的？信息划分的话，有很多种办法，可以一个表写多个字段，自己区分哪些是哪一类；想美观点的可以分多个 model，做一对一关联。RDBMS 就只能这样划分了。其实我想说的是，信息划分纠结的原因之一，是 RDBMS 对数据存储的限制。
这点 MongoDB 之类的文档数据库解决的更好，不用纠结为某一类用户单独开的字段强制应用在其他类型用户中，按信息划分，可以做成嵌套数据也可以做关联。不过实现上我还是觉得直接存字段更直观，搞太科学了 ORM 层面的校验和存储又麻烦了。。。