一、分层模型基础理论
1. 核心定义
分层架构（Layered Architecture）模型是一种常见的软件设计架构，它将软件系统按照功能划分为不同的层次，每个层次都有特定的职责和功能，层与层之间存在清晰的依赖关系。这种架构有助于提高软件的可维护性、可扩展性和可复用性。
常见分层结构
虽然不同的应用场景和系统可能会有不同的分层方式，但比较经典的是分为四层，分别为表示层、业务逻辑层、数据访问层和数据层。
分层架构的一个特性就是关注分离(separation of concerns)。在层中的组件只负责本层的逻辑。组件的划分很容易让它们实现自己的角色和职责，也比较容易地开发，测试管理和维护。
1. 表示层（Presentation Layer）
定义：也称为用户界面层（UI 层），是用户与系统进行交互的接口。它负责接收用户的输入，并将系统的处理结果展示给用户。
职责：提供友好的用户界面，处理用户的请求和操作，如页面渲染、事件处理等。
实现技术：在 Web 应用中，通常使用 HTML、CSS、JavaScript 等前端技术实现；在桌面应用中，可能使用 JavaFX、Swing（Java）、Windows Forms（.NET）等技术。
示例：在一个电商网站中，商品列表页面、购物车页面等都是表示层的一部分，用户可以通过这些页面浏览商品、添加商品到购物车等。
2. 业务逻辑层（Business Logic Layer）
定义：也称为领域层，是系统的核心层，负责处理业务逻辑和业务规则。它接收来自表示层的请求，调用数据访问层获取数据，进行业务处理，并将处理结果返回给表示层。
职责：实现系统的业务逻辑，如订单处理、用户认证、权限管理等。确保业务规则的一致性和正确性。
实现技术：可以使用各种编程语言和框架来实现，如 Java 的 Spring 框架、Python 的 Django 框架等。
示例：在电商系统中，当用户提交订单时，业务逻辑层会检查库存是否充足、计算订单总价、生成订单记录等。
3. 数据访问层（Data Access Layer）
定义：也称为持久化层，负责与数据库或其他数据存储系统进行交互，实现数据的增删改查操作。它将业务逻辑层的请求转换为对数据存储系统的具体操作。
职责：封装数据访问细节，提供统一的数据访问接口，提高数据访问的效率和安全性。
实现技术：使用数据库访问技术，如 JDBC（Java）、ADO.NET（.NET）、SQLAlchemy（Python）等。
示例：在电商系统中，数据访问层负责从数据库中查询商品信息、保存用户订单信息等。
4. 数据层（Data Layer）
定义：也称为数据存储层，负责存储系统的数据。可以是关系型数据库（如 MySQL、Oracle）、非关系型数据库（如 MongoDB、Redis）、文件系统等。
职责：提供数据的持久化存储，确保数据的安全性和完整性。
示例：在电商系统中，数据层存储了商品信息、用户信息、订单信息等。
- 注意每一层都是封闭的。这意味着Request必须经过每一层才能到达最底下一层。
- 这就是分层架构的另一个特征：层隔离(layers of isolation)。层隔离的概念意味着你对任何一层的改变都不会影响其它层。一个层的组件并不会了解其它层的实现，或者知道很少。
- 分层架构也很容易增加新的层。 比如你想将一些通用的服务重构成一个服务层，比如通用图片处理，远程账户审计等，可以在业务层下增加一个服务层。它不会对展示层造成影响，也不会改变持久层的代码。
- 因为每一层丢失封闭的，业务层不得不通过服务层访问持久层，这没有天理啊。 所以有时候你会创建一个开放的层。这意味着上一层可以绕过这一层直接访问下一层。
典型场景包括：
- OSI网络模型（物理层→应用层7层结构）
- J2EE经典分层（Web层→Service层→DAO层）
2. 核心原则
单向依赖：Layer N只能调用Layer N-1（严格分层）或更底层（宽松分层）
契约协议：层间通过标准化接口通信（如REST API、RPC接口）
同层自治：每个层级内部实现技术无关性（如DA层可替换MySQL为MongoDB）
