层

层的定义

• 层：软件的逻辑单元
• 每一层都有特定的功能
• 组件被分配到不同的层

何谓分层

• 将系统按照职责拆分和组织
• 上层依赖于直接下层
  • 下层不可以依赖于上层
  • 不可以跃层访问（理想状况）

经典分层架构

OSI 7 层架构

CS

• 两层架构
• Client：运行于Desktop的Native富客户端
• Server：应用服务、业务逻辑和数据存储
• 通过网络交换信息

BS

• 两层架构
• Browser：运行于各种浏览器的瘦客户端
• Server：应用服务、业务逻辑和数据存储
• 通过网络交换信息

企业应用三层架构

• Presentation：与用户交互和呈现信息
• Domain：业务逻辑
• Data：数据存储
  

缘何分层

• Conway’s Law

  • 设计系统的架构受制于产生这些设计的组织的沟通结构

• 复杂度隔离

  • 隔离业务复杂度和技术复杂度
  • 解决不同层的问题可以采用不同的技术栈
  • 每层变化速度不一致

• 防止错误传播

  • 降低错误影响
  • 防水仓设计

• 层自治

  • 本层功能内聚
  • 自主决策
  • 只有本层的知识
    • 知道的越少，泄密的可能性越少
    • 对外界的依赖少，受影响的可能性小
      

分层架构的优缺点

优点

• 高内聚

  • 每一层的任何变化最多影响自身和上一层
  • 专注自身功能，其它层的影响被屏蔽
  • Single Responsibility

• 低耦合

  • 每一层只依赖于下一层
  • 单向依赖
  • 通过接口交流

• 易扩展

  • 功能扩展，仅影响本层
  • 内聚性，易于横向扩展
  • 独立性，易于纵向扩展

• 可维护性好

  • 分工合作，开发者关注点集中
  • 每一层可以依据接口并行开发
  • 每一层功能单一，代码易于理解

• 可测试性好

  • 每层对外提供固定的接口，可以直接测试接口
  • 分层测试
  • Spring Boot
    • @DataJpaTest
    • @WebMvcTest

缺点

• 性能下降
  • 分层必定引入新的通信开销
  • 层信息不能泄露，导致每层都有数据转化发生
  • 不能跨层访问，增加调用链路
• 开发成本上升
  • Full Stack少，且难以培养
  • 跨组织沟通成本
  • 任何变更可能都需要多层的参与

如何设计分层架构

依赖规则

• 越往外越具体，越朝内越抽象
• 外圈是软件，内圈是规则
• 依赖关系只能从外向内

定义职责

• 高层表示规则，底层实现细节
• 逻辑内聚自治分区
• 依据组织职责分工

定义技术栈

• 根据每层的需求各自选定
• 借鉴成功案例
• 部署方式

代码抽象与分层

• 层对外暴露的接口，隐藏实现细节
• 实现依赖于抽象，抽象不可依赖于实现细节
• 代码不跨层调用，只依赖于直接的下一层

集成

• 集成前做单元测试
• 根据接口和技术栈确定集成方式
• 集成联调

案例解析

MVC

• Model：Domain model和业务逻辑
• View：展示数据和用户交互
• Controller：
  • 接收输入并转化为对model的操作
  • 将model转化为view能展示的数据
    

MVP

• MVC的派生变种
• View通过Presenter获得数据而非Model
• Presenter层充当了桥梁，双向绑定
  

MVVM

• Model 层除了自身也包含部分Controller功能
• ViewModel：View的模型、映射、显示逻辑和绑定器
• View：将ViewModel展示在特定界面