关于架构方面的设计与分析 ---for NFR

      我们知道，现在我们过分的关注于FR,但是一款好的应用软件，要想在市场上有一定的占有度，想在同款软件中有一定的竞争优势，在NFR方面一定要下足功夫，响应时间，允许最大登录上限，可维护性等等，这些都是架构师应该考虑的问题。

      架构师，是一个承上启下的作用，负责联系用户，获取用户需求，然后在技术层面与研发人员进行沟通，需要的技术不仅仅是在代码阶段，更个权衡的过程，用一句上课老师说过的话“不想做架构师的程序员，不是一个好的程序员”，这句话足以体现架构师的重要性。架构师是具有技术发言权，方向决策权，和团队人员开发资源调配权的开发团队的TeamLear，也是这个程序的设计者，当然他是这个程序团队的灵魂，极为重要。

    我们现在经常看到一些人抱怨，“怎么反应这么慢？”  “这么多人在线，把我挤掉了？”等，很少有人抱怨“啊 我这个信息出错了！” NFR是用户体验最深的一处，功能需求如果说是硬性指标，NFR就是永无止境的未来，任何一款产品，都无法做到说我的NFR现在最强！只有不断的进步。

   现在解决这些问题，有几点思考的方向：

   1.分层的思想；层次分明，一个好的分层式结构，可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口，负责不同逻辑设计的开发人员就可以分散关注，齐头并进。例如UI人员只需考虑用户界面的体验与操作，领域的设计人员可以仅关注业务逻辑的设计，而数据库设计人员也不必为繁琐的用户交互而头疼了。每个开发人员的任务得到了确认，开发进度就可以迅速的提高，可维护性显著提高，但是牺牲的是效率。开发人员可以只关注整个结构中的其中某一层，可以很容易的用新的实现来替换原有层次的实现，可以降低层与层之间的依赖，有利于标准化，利于各层逻辑的复用。

     2.分布式的思想：分布式数据库，分布式的app server，LOAD分配，让访问的重心从一个单一的数据转移到不同的模块之间，比如，从之前的一个数据库，承接读取和写两方面的压力，到现在分布式数据库一个负责写，一个负责读，这就大大的降低了数据库访问的压力，那么响应时间就会降低，用户体验随之上升。

    3.异步消息机制，等等，从这些角度去思考这些问题很帮助，我们初学者往往过分的关注于FR,这是正常的，但是经过一段时间之后，思维就要发生转变，这样才能让自己不断成长！