程序设计理念

1. 系统分层与职责分离

• 职责分离 (Separation of Concerns)： 确保软件架构中的每一层只专注于一个方面的功能。
• 单向依赖原则： 允许上层组件直接调用下层组件，但严禁下层组件逆向依赖或调用上层组件。

┌──────────────────────────────────────────────┐
│          表现层 (Presentation Layer)          │
│          - 负责与客户端交互、API 路由分配       │
└──────────────────────┬───────────────────────┘
                       │ 仅单向依赖
                       ▼
┌──────────────────────────────────────────────┐
│        业务逻辑层 (Business Logic Layer)       │
│          - 组织核心领域模型与业务闭环流程       │
└──────────────────────┬───────────────────────┘
                       │ 仅单向依赖
                       ▼
┌──────────────────────────────────────────────┐
│            持久层 (Persistence Layer)         │
│          - 数据库操作及 Entity 实体的维护       │
└──────────────────────┬───────────────────────┘
                       │ 仅单向依赖
                       ▼
┌──────────────────────────────────────────────┐
│        基础设施层 (Infrastructure Layer)       │
│          - 屏蔽底层网络、磁盘 I/O 等物理细节    │
└──────────────────────────────────────────────┘

---

2. 边界隔离设计核心驱动力

在任何非玩具型、需要长期维护的复杂系统中，边界层 是实现 解耦、隔离 和 翻译 的关键机制。设计边界层主要受以下三个核心驱动力决定：

2.1. 核心驱动力一：技术隔离（防止技术细节泄露）

核心原则： 核心业务逻辑（Service/Domain Layer）应当保持技术中立，对底层基础设施和框架的实现细节一无所知。

警告

1. 基础设施依赖 (Infrastructure Dependency)

• 场景： 业务逻辑需要执行数据库读写、发送邮件、进行 Redis 缓存操作或调用外部第三方 API。
• 边界设计： 引入 Repository/DAO 接口边界、外部 API 客户端边界。
• 目的： 即使未来底层的邮件服务从 Postmark 换成 SendGrid，或者数据库由 MySQL 切换为 PostgreSQL，也仅需要重写边界层的具体实现，而核心业务服务层代码无须做任何变动。

注意

2. 框架依赖 (Framework Dependency)

• 场景： 使用特定的 Web 框架（如 Spring Boot, Express, Django）或 ORM 框架（如 Hibernate, Prisma）。
• 边界设计： 引入 Controller 边界。
• 目的： 隔离框架特定的依赖和类（如请求/响应对象、特定的 Annotation 注解）。业务逻辑层只应接收和返回纯净的业务 DTO 或领域模型，绝不能感知外部框架的数据结构（如直接引用 HttpServletRequest 或 Flask Request）。

---

2.2. 核心驱动力二：异常与数据转换（协调不同层次的语言）

核心原则： 软件的每个层次都应该使用它自己上下文的数据模型和异常类型，而边界层则充当“翻译官”。

警告

1. 异常翻译 (Exception Translation)

• 场景： 持久层抛出了底层的 SQL 异常（如 sqlite3.OperationalError、TimeoutException），但这对于业务层来说是不透明且不安全的技术细节。
• 边界设计： 引入 Repository 拦截边界 和 外部服务客户端异常包装。
• 目的： 将底层的低级异常转化为更抽象、更有业务语义的异常（如自定义的业务异常或通用的 DataAccessException），防止技术层细节向上层业务溢出。

注意

2. 数据模型转换 (Data Model Conversion)

• 场景： 数据库存储结构实体（Entity）、核心业务流转的领域模型（Domain Model）以及提供给客户端的展示对象（DTO / VO）承担的角色各不相同。
• 边界设计： 引入 Mapper 边界。
• 目的： 确保数据模型只在其所属层次流通。例如，数据库中存储的敏感哈希密码实体只在持久层到业务层校验时使用，在 Controller 对外输出 DTO 时，边界层应将该敏感字段过滤抹除。

---

2.3. 核心驱动力三：保证接口一致性（保障系统对外健壮性）

核心原则： 系统的对外暴露接口必须是绝对稳定、安全且符合契约规范的。

警告

1. 统一响应与全局异常处理 (Unified Response)

• 场景： 系统作为 API 形式暴露服务给终端。
• 边界设计： Controller / Gateway 边界。
• 目的： 在此边界实现全局异常拦截。无论业务逻辑层发生何种技术错误或断言失效，外层都应统一转换为标准格式响应（如带有 Code, Message, Data 字段的 JSON 对象），并输出安全的 HTTP 状态码，避免向用户泄露致命的堆栈详情。

注意

2. 输入拦截与授权校验 (Input Validation & Authorization)

• 场景： 接收来自不安全外部环境的 HTTP 载荷或 RPC 请求。
• 边界设计： 拦截器/过滤器与 DTO 校验边界。
• 目的： 在数据进入核心业务前，完成数据校验（如长度限制、非空限制、XSS 过滤）及权限拦截，保护核心业务领域。

---

3. 面向切面编程 (AOP)

面向切面编程（Aspect-Oriented Programming, AOP）是对面向对象编程（OOP）的重要补充，它专注于将系统中的 横切关注点（Cross-cutting Concerns） 与核心业务逻辑相分离。

                     横切关注点（AOP 切面）
                     ┌──────────────────┐
 ┌───────────────┐   │  - 日志记录      │
 │  业务模块 A   │───┼──- 权限校验      │
 └───────────────┘   │  - 事务管理      │
 ┌───────────────┐   │  - 性能监控      │
 │  业务模块 B   │───┼──- 缓存控制      │
 └───────────────┘   └──────────────────┘

3.1. AOP 核心概念要素

• 切面 (Aspect)： 横切关注点的模块化。它是通知（Advice）和切入点（Pointcut）的结合。
• 连接点 (Join Point)： 程序执行过程中的某个特定位置（如方法调用时、异常抛出时、属性修改时）。
• 通知/增强 (Advice)： 切面在连接点上执行的具体动作。包括前置通知（Before）、后置通知（After）、环绕通知（Around）等。
• 切入点 (Pointcut)： 用于定义在哪些连接点（Join Point）上触发通知。通常通过正则或注解匹配方法。
• 目标对象 (Target)： 被一个或多个切面所增强的业务对象。
• 织入 (Weaving)： 将切面应用到目标对象以创建新的代理对象的过程。

3.2. 典型应用场景

• 安全检查与鉴权： 在所有 Controller 方法调用前，自动校验请求的用户 Token 是否有效。
• 声明式事务管理： 在 Service 层方法执行前自动开启事务，执行成功则提交，抛出未捕获异常则自动回滚。
• 全局性能审计： 监控匹配切入点的核心服务耗时，超过阈值时记录告警。
• 分布式日志链路追踪： 动态织入请求参数与耗时统计，透传 trace_id。