很想写相关的内容，一直以来这方面的东西很杂，自己各方面都多多少少有些总结，但是没有系统的成文，始终觉得是个遗憾。
这是这个系列的第一篇。
本文说的架构，还并不是说的Tier层的架构，这里面不会涉及到分布式、缓存、网络结构等等的布局，而是集中在软件的内部，是代码层级的，考虑这点架构的点，目的是在于帮助我们写出清晰、易维护的软件。
关注点分离(Separation of concerns, SoC)
这个准则应该作为我们开发和架构的指导性的原则。在该原则下，软件应该按照其业务来将软件本身划分成不同的部分，从而进一步降低耦合性，不过，这感觉是句废话，大家好像都懂。
那么首先，关注点是什么呢？
比如说一组对代码有影响的业务逻辑，或对某个具体业务有影响的业务规则。它其实可以很通用，比如针对x86环境优化代码的细节；也可以很具体，比如某个将要初始化的类的名字，只要它对我们是有用的，我们就称它为其中的一个关注点。
举例来说，如果某个软件有个逻辑：是将某些产品高亮显示出来，以显示这些产品的独特性。
那么，把这些产品挑选出来的逻辑，应该和把这些产品做高亮的逻辑分离开来，这是两个不同的关注点（只是刚好这两个关注点是互相关联的而已）。
在架构上，如何去应用这条准则呢？比如说，把业务逻辑的行为分成基本的实现层（infrastruture）和UI层（理想的情况下，业务规则和业务逻辑都应该分离到不同的项目里面去，他们也不能互相产生依赖的关系）。这种结构能帮助我们保证业务逻辑更容易的测试和应用，而且在底层也没有互相耦合在一起。
关注点分离是我们对于软件分层的一个核心的考虑点。
把握好这个尺度，有助于我们建造模块化的应用程序。它的价值在于简化开发和提高维护性。这个准则做好了，各独立部分就能重用，也可以相对独立的开发和更新，某个模块更新了，其他的模块不必做额外的修改。
