对于架构的一些看法

世界上并没有完美的程序，但是我们并不因此而沮丧，因为写程序就是一个不断追求完美的过程。

自从进入软件行业以来，对于代码结构，我总是想着去追求一些新的东西，总是想办法写出与通用的结构不一致的简单的封装。差不多4年了，我曾尝试自己写过代码自动生成，自己封装过通用的框架，自己实现过一些工具类，但是目前没有一个是非常满意的。现在突然有一些感悟，分享出来，希望对大家有帮助。其实有些东西的创新是内在的、微小的、循序渐进的甚至是自己思想上的，你认识的深入，比形式上的特殊表现更重要。

第一条法则：最正常的架构就是最好最稳定的架构
第二条法则：最好的架构不是有多复杂多抽象而是有多合理
第三条法则：不要追求外在表现的特殊性，同样的三层结构，
设计出来的可以是码农，也可以是架构师，
关键是用起来有多舒服

下面是对于各层的理解，当然只是代码结构，至于更大一些的系统间的架构，其实是可以以小见大，思想是不变的。

entity：
    描述：实体层，一般通用性较大
dao：
    描述：数据解耦层，这里封装的是最最基本的原子操作，
          通过接口实现了与service层的解耦，如果原子操作实现发生了变化，
          只需要修改dao的实现，不会对service层有任何影响
          
service：
    描述：业务解耦层，service接口指明具体业务，而service接口的实现
          则封装了整个业务逻辑，对于较复杂的业务逻辑，在service接口
          与service实现之间加一层抽象service，以模板的形式封装业务
          流程，然后将具体的实现封装到service的实现中，这样在修改时
          就可以避免影响核心流程，只实现具体的外围逻辑即可，比如将
          参数获取与判断装载等放到service的实现中，将流程抽象出来
          放到service的抽象层中
          service
          abstractService
          serviceImpl
          
controller：
    描述：控制转发层，用来接收与返回数据，不做任何具体的操作
     
关于分包：
    最好每个业务分成一个包，
    主要体现在dao和service层，如：dao.stat, dao.visit
    如果可能的话，entity也要分层，如：entity.stat, entity.visit
    前期的繁琐是为了后期的解耦，如果有需要，冗余也可以

使用抽象工厂管理基础的对象
使用构造注入注入需要的对象
使用final标注注入对象的唯一性

使用业务工具类代替通用工具类
关于工具类，工具类就要有通用性
如果是为某一个业务服务，可以专门以工具类为基础将该业务需要的工具类的功能封装
为一个某业务工具类，这样哪怕有一个业务工具类的实现要改变，也不会对全局造成
影响            

传统有其合理性，至于具体实现要遵循设计原则

当然这并不代表我就妥协了，而是更加激发我去更深层次的思考这个问题，既然身处当下，追求新奇是永不止步的！