如下几个原则是必要的，也是今后落实代码时候要注意的：
- 数据类本身应该对自身的数据完整负责，加解密负责；
- 处理逻辑的对象尽量不要包含数据；
- 非数据验证的工具类抽取出来存放在单独的Utils类；
- 数据类的验证工具如果发现有复用，就要考虑对象是否有继承关系或者是共用一个接口，抽象出接口；
- 逻辑复杂的方法一定要降低复杂度，代码控制到20行以内一般就能够轻易地找出bug；
- 如果发现一个对象，经常是几部分数据互斥出现使用的，要考虑拆分成多个对象。
月度归档： 2016 年 6 月
网络层级划分
OSI七层就不说了，在transportion描述的太详细了，其实可以归结为五层。
即是：
应用层（Application）：Http，P2P这种，基本考虑的是字符串，内容。
运输层（Transportation）：传输层用于确定应用层的消息用什么方式传输（可靠地传输或者是不可靠的传输，是否要流量限制等等）
网络层（Network）：负责选择路径的层面（两个节点间会有大于等于一个的路由）
链路层（Data Link）：协商每两个具体节点间的通信细节（直觉上认为是两个直达节点，没有第三个路由器之间的节点）
书
构架即未来
计算机编译原理
感觉还是要好好补全知识体系，为以后向业务架构师努力。
不过也发现以前要是大学时候能看到一些书就好了，比如微积分和当代通信的关系，他们之间是如何连接在一起的。大学都只会傻乎乎的人云亦云的说某某某没有用不用学。可惜老师也说不清学了有什么用，人总是功利的=。=只能说我只是一个俗人咯，该好好学的时候没有好好的学。。。