系统架构的思维

没有系统架构的思维，什么也干不了。在很多系统开发的过程当中，用户是不知道自己的需求的，因为用户不会用架构师的思考方式去思考。

架构思考是干什么的？架构思考的关键就是要了解整个业务需求到底是什么？然后要用表和网页的逻辑去思考。

一个表的CRUD代表着一个系统思维；绝大多数的业务需求几乎都是一个列表点一个修改详情。

比如给这个学员选一门课，然后这门课再选一个老师，这个课再加一个老师；全部都是一个列表，然后对这个列表进行增删改查。

必须有一个对数据库表的很清晰的概念：我们在做数据库培训的时候，有一个班级的表，一个学员的表，一个课目的表，还有一个老师的表；然后哪个老师是教哪个课目；课目连到哪个班；哪个班都有谁；都是这样表。

我们需要从这样的细节当中跳出来，把自己变成一个架构师：

一看到一个业务，上来肯定是一个表再加一个表，再加一个表，然后再加一个链接；有一个连接表；所以我们总结为一个表的应用，两个表的应用，三个表的应用

要从代码里出来，抽象出架构的思考。

当看到一个业务最先想到的是什么？最先想到的就是这个表长什么样？然后再想页面长什么样？

架构师看到业务应该怎样思考？

比如学校的管理是什么？学习的管理就是学生；学生分到哪个班，小学生就一个班，老师可以到很多班去上课；一张表就可以完成（学生的名，学生的班级，学生联系方式）；但遇到重名的就是问题了；那就需要一个学号identify/Id；

名字会重复，身份证太长容易写错，架构师会设计一个学号，这个学号是唯一的，不会重复出现；架构师的思考，最重要的一个东西叫做'Key',数据库的表格一定要有一个字段，能够独立地识别那一行东西；一般学校的混乱就是没有架构师替他思考。

只要一个页面需要做增删改查，数据里就要有ID，所有的东西都要有ID；班级有班级的ID，学生有学生的ID，课目有课目的ID；ID是不能重复的。不可重复性是一个系统架构师最先要学习的。

学生有学生的，班级有班级的，课目有课目的，它们之间彼此连接就形成课表；课表有课表记录的ID，到时候就按着这个记录的ID进行修改。

要逐渐养成对数据表格深刻的认识；增删改查的关键就是所对应的ID，看数据里有没有这个ID？没有这个ID，那就天下大乱。

架构师的第一件事就是ID！

尽量不要用一张表解决问题；有一张表是学生表，一张表是课目表，把课目表和学生表放在一起，可以吗？在小学可以；但在某一个阶段这个学生突然增加了其它课程，就比较麻烦了；所以尽量不把东西放成这样；作为架构师必须考虑到将来会有别的问题出现？高中、大学开始分科，会有默认的班级 ，还有其它的班级。

学校的管理系统很简单，就是学生、老师、科目、班级，还有就是财务。

ID是事先创建好还是来一个创建一个？都可以。

架构师最关键就是把数据库的表整对，数据最关键就是那个ID；把一个表、两个表、三个表、、、连起来。用4个表能解决的问题千万不要用40张表

把事情干简单了成本低！

数据库、表的思考，把几张表连接起来，有一对一的关系；一对多的关系，学生和班级是一对多的关系，班级就不能放在学生表里；还有多对多的关系；所有的表都是这样，连接就靠上面我们所提到的ID。

所有的页面到数据库就是SQL，所有页面一操作一提交，就把SQL 更新了；

通讯协议必须是架构师思考的内容；架构师最重要最重要的是把业务分析完，就变成了页面长什么样？数据长什么样？还有算法长什么样？

对于页面来讲，什么时间输入这个数据？跟这个系统一点关系都没有；架构思考，要有全局观；在设计系统的时候，把相关的因素考虑到，不相关的因素不考虑

架构师在看到一个业务的时候，是从数据表格和整个页面，页面实际上就是一个业务流程 ：谁进到这个页面应该看到啥？一件事干完有很多只手在里面

比如一个学生入学，他首先要到教务处去报道，然后到财务那边去付费，再要去安排宿舍部门安排宿舍、、、

要有一个表的思考，表的下面是字段，作为架构师需要清楚什么数据需要收集？什么数据不需要收集？什么数据必须收集对？

什么数据会影响逻辑不能瞎填；这都是架构师必须思考的！

做一个产品经理需要用一个架构师的眼光去看这个业务；所有IT业务的成败都在这一个人的身上；作为一个业务人员，需要有数据思考的方式，这是企业管理者必备的技能；编程人员必须有这个业务的知识，彼此一沟通，很多细节就被敲定，软件系统几乎没有失败的几率。