世界上并没有完美的程序，但是我们并不因此而沮丧，因为写程序就是一个不断追求完美的过程。
架构设计的目的主要是为了提高程序功能以外的特性，架构设计中非常重要的一点是解耦，解耦的重点是业务逻辑的解耦，业务逻辑的承载就是Service，在前面对架构的一些看法中，提出了在service与impl之间加一层abstract通过模板方法的设计模式用以封装最最核心的业务流程，以保证真正核心的稳定性。
但是今天在开发过程中突然又想到一个问题，在我们的开发中，通过dao接口实现了业务层（servie）与数据层（dao）的解耦，但是对于业务层（service）与控制层（controller）之间呢？在我的设计中，控制层(controller)的作用只是控制转发，并不接收参数，参数的接收与校验由业务层(service)的impl处理，然而这种设计显然并不合理，因为如果想要把业务层(service)作为一个独立的构件，那么业务层就应该有独立测试的能力，与网络相关的好多处理就不应该放在service层中，所以为了实现service层与controller层的彻底解耦，我在service层与controller层之间增加了一个convertor层，这一层的作用就是为了接收参数与一些网络相关的处理，如设置跨域、请求头、Cookie等。同时会专门为每一个业务设置一个传输实体，专门用来当前业务的传参。重新设计后的结构如下：
controller:
控制转发
convertor：
接收参数，封装传参实体
service：
核心业务
dao：
底层数据处理
entity：
实体
config:
配置
util：
工具
constant:
常量
factory：
抽象工厂
其中每一层内部，都尽可能的以业务为边界区分，使每一个业务都成为一个独立的业务构件系统。其中convertor、service、dao遵循依赖倒置原则使用接口解耦，这样就使业务逻辑完全独立出来了，并且也提高了其稳定性。
