系统架构在代码层面如何分层？分层的目的是什么？合理分层的好处有那些？具体如何操作？以下简单总结。
传统的最基础的分层，指MVC，即Model、View和Control三层，但在具体架构时，这种分层太笼统，不利于具体的执行，需要在上面分层的基础上根据业务再细分。
分层主要要考虑两个维度的问题，第一是技术维度，第二是业务维度。
从技术面上来讲，合理分层，减少层之间的耦合，第一方便开发人员之间的协用，另一方面，也是我认为比较重要的方面，即对系统架构升级的影响。
开发人员之间的协作就不需要再说了，主要说明一下对系统架构升级的影响。
一个产品使用一定时间段后，需要对产品进行技术方面的升级，以适应用业务发展的需要，这里不包括那种业务基本稳定、系统可以很长时间不需要调整的系统，因为这类系统架构升级的动力不足，因为其一、升级需要比较大的人力、财力的投入，也需要一定的时间， 其二，对业务的冲击不得不考虑，用户需要能接受这种冲击。
这里所说的架构升级，主要指系统级的架构升级，如从烟囱状的架构升级为分布式的、再到微服务、云化等，可以定义为一个产品的系统级的重架，牵扯的方方面面比较大，但又在业务或其它方面的要求下，必须要完成升级。
要降低这种架构级升级的难度，最为关键的，就是系统研发时的合理分层、功能的合理划分。架构升级的一般前提是，业务层面的调整相对可控，升级的难度主要集中的在架构，即技术本身，需要关注技术层面的升级的影响，那在这种需要的前提和要求下，代码架构层面如何分层？
首先MVC是必须要有的， 我们需要这类大架构下，再细分。先从最下面向上逐层说明。
1、DAO层
现在的业务环境下，DAO层需要支持的不同的数据存储对象，除关系数据库外，还需要考虑Hadoop、MongoDB、Reids、HBase、Hive等等。
从职责上来讲，DAO只负责存储的处理，即数据存进去、读出来，不负责其它逻辑的处理。这个和大家的通用的作法一致。
2、Service层
这个是通俗意义上的业务逻辑层，一般的情况下，业务逻辑的处理基本会分布在这个层中。但如果将所有的业务逻辑全部写到Servcie中，显然是不合适的，因为业务逻辑也是可以再分类的。根据实际经验，对通用的业务逻辑，需要增加Manager层，专门用于管理通用的业务逻辑，供所有的地方调用，而Servcie中只处理特有的业务逻辑，通过这样的处理，实际上相当于对业务进行再分层管理，强化了业务的通用性，降低开发量，同时也可以避免因为不同人员对同一业务的理解不同，造成的处理不同。
还有重要的一点意义，即系统架构升级时，业务变动基本处于可控范围内，Manager层的增加，相当于对业务提供了一个缓冲层，降低了对业务的冲击，有利于系统架构的升级。
3、Manager 层
相对于mvc的结构，这个是通过业务驱动增加出来的一个专门用于业务逻辑处理的层，但他不处理所的业务逻辑，主要侧重于通用的业务逻辑，和Service层有一定的重叠，职责划分上不象其它层那么清晰，具体执行时需要根据业务的情况，具体对待。
4、Control层
这个是MVC中重要的一层，但更多的做法中，这个层中有一定的业务处理逻辑，这个是不妥当的，业务处理需要放到Service或Manager层中，而不是Control层，如果这个层中包括太多的业务逻辑，对后续的系统升级都会带来影响。
5、View层
这个就没有什么需要注意的了
系统开发中，的确需要注意可能给系统升级带来的影响，通过合理的分层划分，以及对业务的抽象和归并，可以适当的降低升级难度。
