说起架构，大多数【程序员】可以如数家珍的说出好几种架构，千人千面，不同的架构解决问题的侧重点有所不同，【程序】设计大多数是多种架构的混沌使用，只是以某一种架构作为主导来支配软件，OK，借助于此话，引出我们要讲解的软件架构之一--- 【分层架构】，说他是所有架构的鼻祖，有点勉强，但是该架构存在的历史足够的悠久，我们姑且称之为【架构鼻祖】吧，于此同时，它【分层架构】也是所有架构的基础，绝大多数架构多多少少都建立再【分层架构】基础之上。
【分层架构】作为一种架构模式，他本身支撑N层架构系统，因此被广泛的应用于Web、企业应用以及C/S模式的桌面应用。该架构的显著特点是 把一个应用系统进行有效的分层处理，同时又作为一个整体为用户提供其服务。其中，为我们【程序员】津津乐道的分层架构的代表便是 MVC架构，再国内基本已经是Web业务系统开发的行业标准了。
分层架构有其显著的原则：每层只能与位于其下方的层发生耦合。基于这个原则，分层架构有可划分为：严格分层架构与松散分层架构，后者使用范围更加的广泛，毕竟 基础设施层作为技术组件服务于每一层，比较难严格遵守 分层架构原则。
事实上，程序中如果存在 EDA 架构的一些引用，一样存在打破分层原则的现象，EDA 所发生的事件，通过EVENT—BUS，可实现跨层传递，这一点 需要额外的指出，如果使用的不是很多，则可作为设计模式而存在，而不把他归结于架构的范畴。
如下展示分层架构一般示意图，如下：
上图为大家所熟知的典型的三层分成架构模型，无论基于什么样子的宏观架构体系（如基于Spring Cloud 或者 阿里巴巴的 Dubbo等），聚焦于业务的具体实现本身，大多场景都会基于该分层模式实现。
但是，作为我自身的出发，我觉得分层架构不仅仅停留在【分三层】的基础之上（MVC三层架构毒害太多入门青少年了），在这里注意，分层架构可不是 分三层架构，于是，结合DDD领域建模的指导思想，我认为更加合理的分层模型如下：
按照上述的分层模型，至少可以把一个系统拆分为5层或者更多层，每一层都有个自己的职责所在，或提供业务服务、或提供安全拦截等机制，每层都实现承上启下的功能，最终能确保整个应用程序的正常使用。
大家都基于惯性思维，被MVC三层架构所束缚了想象的空间，上述的分层模型是不是最优解呢？不一定，在这里主要是抛砖引玉，给大家拓展一种可能的思维角度，分层架构并不总是一种很呆板的出现再大家的思维模式里，只要合理，就可以基于某种理由把他单独作为层来实现（分层有厚薄），如同上图的【聚合层】。
【分层架构】作为众多架构鼻祖般的存在，我们应该赋予它跟多的解读于理解，MVC作为【分层架构】的经典实现，给我们提供了一些经典的案例与实现，例如 Spring MVC、Struts、Struts2等，但是并不代表全部。条条大路通罗马，在实际的场景中要灵活的使用【分层架构】的思想与规约来进行有效的处理。
在回到我们本章的提到的【分层架构】，佛曰，不注文字，拈花一笑。我写文章的目的也在于此，不要太拘泥于事物本身的定义，活学活用，才是正解。所谓【分层架构】也是实现最终应用的一种渠道而已。针对 非常规的场景，是否有更加合适的架构选型呢？敬请期待………
来源：oschina
链接：https://my.oschina.net/qfhxj/blog/3210464