分层架构的三种划分维度：C/S-B/S、MVC-MVP、逻辑分层架构

[[三种拆分方式对应的典型架构及可组合使用]]里面向流程拆分对应的分层架构（也叫N层架构，N至少是2层，常见3层如MVC/MVP、4层，5层较少见、一般是操作系统内核这类复杂系统才会用到），按不同的划分维度和划分对象，会得到不同风格的分层架构。C/S架构、B/S架构划分的对象是整个业务系统，划分的维度是”用户交互”——把和用户直接打交道的部分独立成一层，支撑用户交互的后台作为另一层。MVC架构、MVP架构划分的对象是单个业务子系统，划分的维度是”职责”——把不同职责划到独立的层，但各层之间的依赖关系比较灵活，比如MVC里各层是两两交互的（不是严格单向）。逻辑分层架构划分的对象可以是单个业务子系统也可以是整个业务系统，同样按职责划分，但和MVC/MVP的关键区别在于它的层是自顶向下单向依赖的，典型代表是操作系统内核架构、TCP/IP架构、J2EE系统架构。无论用哪种维度分层，分层架构设计最核心的一条原则是：必须保证各层之间的差异足够清晰、边界足够明显，让人看一眼架构图就能看懂整个系统——这也是分层不能分太多层的原因，一旦两层之间的差异变得模糊，就会出现程序员小明认为某功能该放A层、程序员老王认为该放B层这种分歧，一旦这种混乱的架构真落地开发，A层和B层就会乱成一锅粥，分层也就失去了意义。

结构图：

flowchart TB
  A["分层架构的三种划分维度"]
  A --> B["C/S、B/S架构<br/>划分对象：整个业务系统<br/>划分维度：用户交互(前端/后台)"]
  A --> C["MVC、MVP架构<br/>划分对象：单个业务子系统<br/>划分维度：职责，层间两两灵活交互"]
  A --> D["逻辑分层架构<br/>划分对象：子系统或整个系统均可<br/>划分维度：职责，自顶向下单向依赖<br/>(操作系统内核/TCP-IP/J2EE)"]
  B --> E["共同要求：各层差异必须清晰<br/>边界必须明显，看架构图即能看懂"]
  C --> E
  D --> E