分层解耦是最常见也被认为是最入门级的架构能力。看似简单，实质具有非常深刻的内涵。
分层的依据有两点，一是职责，另一个是特征。基于职责，软件实体可以根据负载的任务类型不同，把同质化的功能、能力聚合到一个层次中。无论是云计算的IaaS、PaaS、SaaS分层，还是系统软件、中间件、应用分层，还是前后台分层等等，都是基于软件负载的
实质是隔离关注点。依据是软件不同部分具有高度一致的本质。比如WEB开发常见的前端、后端分离，就是建立在前后端具有不同的关注点前提上。前端关注不同的渠道灵活快速支持和用户体验，后端关注服务的沉淀、稳定可靠以及性能容量。<br>当前比较常见的分层还有将领域和应用进行分层，从而获得一个比较稳定的领域能力层，这个是DDD的基本主张，也是当前各种领域PaaS存在的理论参照系。
解耦的实质是分离变化点，这是一种适合不同粒度、不同层次的变化点分离架构方法。大到上面的分层，小到一个功能内的两个实现类，都可以找到解耦方法的影子。
分层与解耦的一个关键**挑战**是最容易被忽略的是只有分和解，没有合。因为软件系统作为一个整体而言，用户对其完成一系列业务case的完整性并没有随着解耦而消失，同时这才是软件产品的根本任务。而解耦只是软件研发组织的内部诉求，不是用户诉求。所以解了以后还要合。“合”比“解”的难度更大。解的同时要考虑合，合要基于解的结果。因此没有先后顺序，要同时考虑解耦与合并才能真正完成“解耦”。
分层是解耦的特例，是完成系统level0的解耦。就企业IT软件看，是完成用户界面、业务逻辑/应用、数据存储几大类IT任务的解耦。围绕着分层有一系列的“合”解决方案的现成实例，如sevlet规范解决界面与业务逻辑的合，jdbc解决业务逻辑与数据存储的合，各类中间件sdk解决业务应用与中间件服务的合。
因此，分层解耦是IT架构最基本也是最有内涵的架构方法。
模块化和简单性是软件工程的基石。蒂姆博纳斯这句充满哲理性的名言可以说准确指明了分层解耦的最终目标或者说最终结果。无论是层次还是一个个有边界的逻辑聚合软件实体，都是一个个模块。无论是高层次的基于特定场景的企业应用、个人消费者应用，亦或是低层次的系统软件，如Linux、Oracle，甚至是编译器软件等等，任何一款软件产品、原型，它的设计者、实现者都会把整个软件系统划分为一个个相互协作的单元，分别实现，再统一整合。这就是软件部分与整体的哲学，是软件实体的内在规律。简单性可以基于划分后的单元是否足够聚焦，是否职责趋于单一。这种简单性你可以通过
分层解耦的好坏取决于软件设计、实现者的水平。主要包括以下几个方面：
* 领域经验，是否能够洞察待解决问题的核心本质，构思软件系统解决方案，这一能力要求必须准确的把握整体解决方案的核心能力要求。基于对整体的理解，进而识别出构成整体的要素，分解为功能层次和单元。
* 技术能力，也就是软件实现能力。必须清晰的为解决方案寻求最佳技术路径。包括技术的能力、竞争力和演进趋势，约束。
组织分工，构建大规模软件的工程基础。
