前端 DDD 与 Clean Architecture 在大型业务系统中的分层架构实践

3. 领域层（核心业务规则）

// 实体：拦截规则（封装业务规则）
export class InterceptionRule {
  constructor(
    public id: string,
    public name: string,
    public condition: string
  ) {
    // 业务规则：规则名称不能为空
    if (!name.trim()) throw new Error('规则名称不可为空');
  }
}

// 服务：拦截池业务操作
export class InterceptionPoolService {
  // 业务逻辑：过滤已过期的规则
  filterExpiredRules(rules: InterceptionRule[]): InterceptionRule[] {
    return rules.filter(rule => rule.condition.includes('expire:false'));
  }
}

4. 基础层（通用技术能力）

// API 请求工具
import axios from 'axios';

export class ApiRepository {
  async get<T>(url: string, params: Record<string, any>): Promise<T> {
    const res = await axios.get(url, { params });
    return res.data;
  }
}

二、架构方案选型：平衡成本与收益

针对前端 DDD 的落地方案，结合项目规模和技术栈（Vue + React），做了量化对比：

最终选型：Vue / React + Clean Architecture —— 既适配当前技术栈，又能以轻量改造成本落地，同时规避长期维护风险。

三、Clean Architecture 设计理念

Clean Architecture 核心是'业务逻辑内聚，外部依赖外移'，其环形分层结构在前端中可映射为更具体的职责，确保核心业务不受技术工具的约束。

这张图的核心规则是'内层不依赖外层'：从内到外依次是'Entities（核心业务）→ Use Cases（应用逻辑）→ Repositories / Presenters（接口适配）→ 最外层的 Device / DB / API / UI（框架与工具）'，确保核心业务逻辑不被外部工具绑定。

3.1 核心原则

• 框架无关：业务逻辑不依赖'Vue 的 ref'或'React 的 setState'等，仅在 UI 层使用框架能力
• 可测试：核心业务逻辑（如 InterceptionRule 的名称校验）可脱离组件，用 Jest 独立测试
• 多端 / 存储适配：扩展至小程序时仅需替换 UI 层，核心逻辑 100% 复用；存储方案可从 localStorage 切换为 IndexedDB，无需修改业务代码

3.2 架构层次

3.3 数据流向

前端请求的全链路流程：

用户操作组件 → Controller（交互调度） → UseCase（业务逻辑） → Repository（API 请求） → 接口数据 → UseCase（业务处理） → UI 组件（渲染） 

各层依赖关系遵循'外层依赖内层'：

View ← Presenter ← UseCase ← Repositories ← Model 

四、目录结构设计

以下是'拦截池'业务模块的目录结构，严格对应 Clean Architecture 的分层，确保各层职责不越界。

├── modules
│   ├── exception-flow # 业务场景：异常流程
│   │   └── interception-pool # 模块名：拦截池
│   │       ├── components # UI 层：模块内组件（对应框架驱动层）
│   │       ├── model # 实体层：业务模型（Entity / Service）
│   │       │   └── interception-pool.ts # 拦截规则实体 + 服务
│   │       ├── repository # 接口适配器层：API 封装 + 数据转换
│   │       │   ├── interception-pool.ts # API 请求方法
│   │       │   └── types.ts # 接口类型定义
│   │       ├── usecase # 用例层：业务操作（对应图 2）
│   │       │   ├── interception-pool.ts # 通用用例
│   │       │   ├── interception-pool-for-sip.ts # Sip 仓扩展用例
│   │       │   └── usecase-factory.ts # 用例工厂（映射场景）
│   │       ├── controller.ts # 控制层：交互逻辑调度
│   │       ├── index.vue # 模块入口：组装组件与逻辑
│   │       └── README.md # 模块使用文档

4.1 Model 层（实体层）

对应 Clean Architecture 的实体层（Entities），是核心业务规则的载体，区分'接口实体（Entity）'和'UI 模型（Model）'两类数据类型。

• Entity：后端接口返回的原始数据类型，与后端协议强绑定
• Model：前端 UI 组件使用的数据类型，可根据展示需求调整字段格式 / 命名

代码示例：Model 层设计

// model/interception-pool.ts
// 1. Entity：后端接口返回的原始类型（与 API 协议一致）
export interface InterceptionRuleEntity {
  rule_id: string;     // 后端字段：规则 ID
  rule_name: string;   // 后端字段：规则名称
  rule_condition: string; // 后端字段：规则条件
  expire_flag: string; // 后端字段：过期标识
}

// 2. Model：前端 UI 使用的类型（适配组件展示）
export interface InterceptionRuleModel {
  id: string;          // 前端字段：规则 ID（统一命名）
  name: string;        // 前端字段：规则名称
  condition: string;   // 前端字段：规则条件
  isExpired: boolean;  // 前端字段：是否过期（布尔值，便于 UI 判断）
}

// 3. 数据转换函数（Entity → Model）
export const mapRuleEntityToModel = (entity: InterceptionRuleEntity): InterceptionRuleModel => ({
  id: entity.rule_id,
  name: entity.rule_name,
  condition: entity.rule_condition,
  isExpired: entity.expire_flag === 'true'
});

核心价值

通过类型分离与转换，隔离后端协议变更对前端 UI 的影响——若后端字段 rule_id 改为 id，仅需修改 mapRuleEntityToModel 函数，无需调整 UI 组件。

4.2 Repository 层（接口适配器层）

对应 Clean Architecture 的接口适配器层，是前端与后端 API 的'桥梁'，核心职责是封装 API 请求逻辑，屏蔽接口细节对上层的影响。

• 封装 API 请求方法（GET / POST / PUT / DELETE）
• 处理请求参数格式化（如：分页参数、时间格式）
• 统一处理接口异常（如：401 / 500 错误）
• 转换接口返回数据（Entity → Model）

代码示例：Repository 层设计

// repository/interception-pool.ts
import axios from 'axios';
import { InterceptionRuleEntity, InterceptionRuleModel, mapRuleEntityToModel } from '../model/interception-pool';

// 接口参数类型
export interface QueryInterceptionRulesParams {
  pageNum: number;
  pageSize: number;
  type?: string; // 规则类型（如 sip 仓/普通仓）
}

export class InterceptionPoolRepository {
  // 基础 URL
  private baseUrl = '/api/interception-rules';

  // 查询拦截规则列表
  async queryRules(params: QueryInterceptionRulesParams): Promise<InterceptionRuleModel[]> {
    try {
      // 1. 格式化请求参数（统一分页参数命名）
      const formattedParams = {
        page_num: params.pageNum,
        page_size: params.pageSize,
        type: params.type
      };

      // 2. 发送 API 请求
      const res = await axios.get<InterceptionRuleEntity[]>(this.baseUrl, { params: formattedParams });

      // 3. 转换数据格式（Entity → Model）
      return res.data.map(mapRuleEntityToModel);
    } catch (error) {
      // 4. 统一异常处理
      console.error('查询拦截规则失败：', error);
      throw new Error('查询拦截规则失败，请重试');
    }
  }

  // 创建拦截规则
  async createRule(rule: Omit<InterceptionRuleModel, 'id'>): Promise<void> {
    // 转换 Model → Entity（适配后端接口）
    const entity = {
      rule_name: rule.name,
      rule_condition: rule.condition,
      expire_flag: rule.isExpired ? 'true' : 'false'
    };
    await axios.post(this.baseUrl, entity);
  }
}

核心价值

UseCase 层无需关心 API 的具体路径、参数格式，仅需调用 Repository 的方法，实现'业务逻辑与接口细节解耦'。

4.3 UseCase 层：复用与扩展的设计

对应 Clean Architecture 的用例层，该层采用'抽象接口 + 继承复用'的设计模式（符合开闭原则），通过'定义契约 - 封装共性 - 扩展个性'的分层逻辑，实现业务逻辑的复用与场景扩展的解耦。

4.3.1 类图与设计模式解析

类图对应'接口抽象 + 继承复用'的设计，各元素的核心职责如下：

• InterceptionPoolUseCase（抽象接口）：定义拦截池业务的核心能力契约，规范所有用例必须实现的方法
• DefaultUseCase（通用实现）：继承抽象接口，封装所有场景的共性逻辑（如：参数格式化、基础数据查询、通用业务规则）
• SipWhUseCase（扩展实现）：继承通用实现，重写个性化逻辑（如：Sip 仓的特殊参数、专属业务规则）

4.3.2 分层设计细节

1. 抽象接口：定义核心能力契约

抽象接口是 UseCase 层的'能力清单'，确保所有用例都实现统一的核心方法，避免场景扩展时出现能力缺失。

// usecase/interception-pool.ts
// 对应类图中的「InterceptionPoolUseCase」抽象接口
export interface InterceptionPoolUseCase {
  /**
   * 处理请求参数（共性/个性参数格式化）
   * @param params 前端传入的原始参数
   * @returns 格式化后的接口请求参数
   */
  processParams(params: any): any;

  /**
   * 获取拦截规则列表（核心业务操作）
   * @param params 前端传入的查询参数
   * @returns 处理后的 UI 模型列表
   */
  getList(params: any): Promise<InterceptionRuleModel[]>;
}

核心价值：通过接口约束，保证所有拦截池场景（普通仓 / Sip 仓 / 临时仓）都具备'参数处理 + 列表查询'的核心能力，统一业务操作的调用方式。

2. 通用 UseCase：封装共性逻辑

DefaultUseCase 对应类图中的通用实现，负责封装所有场景共享的逻辑，避免重复代码。

// 对应类图中的「DefaultUseCase」
export class DefaultInterceptionPoolUseCase implements InterceptionPoolUseCase {
  // 对应类图中的「+repository: Repository」：依赖 Repository 层
  protected repository: InterceptionPoolRepository;

  constructor() {
    this.repository = new InterceptionPoolRepository();
  }

  /**
   * 通用参数处理：格式化分页/通用筛选条件
   * 对应类图中的「+processParams」
   */
  processParams(params: any): any {
    // 共性逻辑：统一分页参数命名（前端 page→后端 page_num）
    return {
      page_num: params.page || 1,
      page_size: params.pageSize || 10,
      keyword: params.keyword || ''
    };
  }

  /**
   * 通用列表查询：参数处理→调用接口→数据转换→基础业务逻辑
   * 对应类图中的「+getList」
   */
  async getList(params: any): Promise<InterceptionRuleModel[]> {
    try {
      // 步骤 1：调用通用参数处理
      const formattedParams = this.processParams(params);

      // 步骤 2：调用 Repository 层获取接口数据
      const ruleModels = await this.repository.queryRules(formattedParams);

      // 步骤 3：通用业务逻辑：过滤空名称的无效规则
      return ruleModels.filter(rule => rule.name.trim());
    } catch (error) {
      // 共性异常处理：统一业务层面的错误提示
      console.error('获取拦截规则列表失败（通用逻辑）：', error);
      throw new Error('查询规则失败，请检查网络后重试');
    }
  }
}

共性逻辑封装点

• 参数格式化：统一分页参数、通用筛选条件的处理
• 接口调用：复用 Repository 层的查询逻辑
• 基础业务规则：过滤无效数据、统一异常提示

3. 扩展 UseCase：实现个性化场景

SipWhUseCase 对应类图中的扩展实现，继承通用 UseCase 的共性逻辑，重写个性化方法，适配特定场景（如 Sip 仓）。

// 对应类图中的「SipWhUseCase」
export class SipWhUseCase extends DefaultInterceptionPoolUseCase {
  /**
   * 重写参数处理：添加 Sip 仓专属筛选条件
   * 对应类图中的「+ processParams」（重写）
   */
  processParams(params: any): any {
    // 复用父类的通用参数处理逻辑
    const baseParams = super.processParams(params);
    // 个性化逻辑：强制添加「type: 'sip'」的筛选条件
    return { ...baseParams, rule_type: 'sip' }; // Sip 仓专属参数
  }

  /**
   * 重写列表查询：补充 Sip 仓专属业务逻辑
   * 对应类图中的「+ getList」（扩展）
   */
  async getList(params: any): Promise<InterceptionRuleModel[]> {
    try {
      // 复用父类的「参数处理 → 接口调用 → 基础过滤」逻辑
      const baseRules = await super.getList(params);
      // 个性化业务逻辑：过滤 Sip 仓的跨境规则
      return baseRules.filter(rule => !rule.condition.includes('cross_border: true'));
    } catch (error) {
      // 个性化异常提示：区分 Sip 仓场景的错误
      console.error('获取 Sip 仓拦截规则失败：', error);
      throw new Error('Sip 仓规则查询失败，请联系管理员');
    }
  }
}

扩展逻辑点

• 重写 processParams：添加 Sip 仓专属参数 rule_type: 'sip'
• 扩展 getList：在通用逻辑基础上，新增'过滤跨境规则'的个性化业务

4. 用例工厂：场景与 UseCase 的映射

为了让上层（控制层）无需关心 UseCase 的实例化细节，通过用例工厂实现'场景 → UseCase'的自动映射。

// usecase/usecase-factory.ts
export class InterceptionPoolUseCaseFactory {
  /**
   * 根据场景类型创建对应的 UseCase 实例
   * @param scene 业务场景（default/sip）
   * @returns 对应场景的 UseCase 实例
   */
  static create(scene: 'default' | 'sip'): InterceptionPoolUseCase {
    switch (scene) {
      case 'sip':
        return new SipWhUseCase(); // 场景对应 Sip 仓 UseCase
      default:
        return new DefaultInterceptionPoolUseCase(); // 默认对应通用 UseCase
    }
  }
}

4.3.3 实际业务场景中的调用

在控制层（Controller）中，通过用例工厂选择对应场景的 UseCase，实现业务逻辑的'按需调用'。

// controller.ts
import { ref } from 'vue';
import { InterceptionPoolUseCaseFactory } from './usecase/usecase-factory';
import { InterceptionRuleModel } from './model/interception-pool';

export function useInterceptionPoolController(scene: 'default' | 'sip' = 'default') {
  const loading = ref(false);
  // 通过工厂获取对应场景的 UseCase 实例
  const usecase = InterceptionPoolUseCaseFactory.create(scene);
  const ruleList = ref<InterceptionRuleModel[]>([]);

  const getRuleList = async (params: any) => {
    loading.value = true;
    try {
      // 调用 UseCase 的 getList 方法（不同场景自动适配逻辑）
      ruleList.value = await usecase.getList(params);
    } finally {
      loading.value = false;
    }
  };

  return { loading, ruleList, getRuleList };
}

场景调用示例

• 普通仓页面：useInterceptionPoolController('default') → 调用通用 UseCase
• Sip 仓页面：useInterceptionPoolController('sip') → 调用 Sip 仓扩展 UseCase

4.3.4 设计核心价值

这种'抽象接口 + 通用继承 + 扩展重写'的设计，完美适配大型前端系统的业务迭代需求。

1. 高复用性：共性逻辑（参数格式化、基础查询）仅需写一次，所有场景复用
2. 易扩展性：新增场景（如'临时拦截池'）时，只需新建 TempInterceptionPoolUseCase 继承 DefaultUseCase，重写个性化方法即可
3. 可维护性：业务逻辑分层清晰，通用逻辑的修改（如分页参数变更）仅需改 DefaultUseCase，就会同步到所有扩展场景
4. 符合开闭原则：扩展新场景时'不修改原有代码，只新增代码'，降低迭代风险

4.4 Presenter 层：前端的简化实现

Presenter 层是 Clean Architecture 中领域层与 UI 层的专属展示适配器，核心定位是做'业务数据到展示数据'的最后一步转换，但前端因组件化、展示逻辑与视图强耦合的特性，未单独抽离物理层做实现，而是采用'职责保留、逻辑分散'的轻量化落地方式。

本节重点明确 Presenter 层的原生核心职责、与 Repository 层的本质区别，并详解前端场景下的简化实现方案。

4.4.1 原生定位与前端简化的核心原因

1. Clean Architecture 中的原生定位

在 Clean Architecture 环形分层中，Presenter 层属于接口适配器层的展示侧实现，位于 UseCase 层与 UI 层之间，核心职责是将 UseCase 层处理后的通用业务 Model 转换为完全贴合 UI 展示的 View Model，并屏蔽所有业务逻辑对 UI 层的影响，是纯展示维度的适配层。

2. 前端未单独抽离实现的核心原因

结合前端组件化开发的特性，单独创建 Presenter 物理层（如新建 presenter 文件夹）会造成层级冗余、逻辑跳转成本高，因此采用轻量化实现，核心原因有三点：

• 展示逻辑与 UI 强耦合：前端展示适配不仅是字段转换，还包含'根据字段判断样式 / 显隐 / 按钮状态'等与组件紧密绑定的逻辑，抽离后需频繁传参，降低开发效率
• 数据适配粒度差异：后端接口到前端通用 Model 的转换是全局统一的结构适配，而 Model 到 View Model 的转换是组件专属的展示适配，分散在组件内更贴合前端开发习惯
• 避免过度设计：多数中大型前端项目中，展示适配逻辑轻量且分散，单独抽离层会增加模板代码，违背'轻量改造'的架构初衷

4.4.2 与 Repository 层（接口适配器层）的核心区别

Presenter 层与 Repository 层虽同属适配器范畴，均承担'数据转换'职责，但二者的适配目标、转换阶段、职责边界有本质区别，也是前端架构中需明确的核心分层原则，具体区别如下表所示：

核心区分

• Repository 层解决'后端数据怎么适配前端业务逻辑'的问题，转换后的 Model 是前端业务层的通用数据
• Presenter 层解决'前端业务数据怎么适配 UI 组件展示'的问题，转换后的 View Model 是仅服务于渲染的专属数据

4.4.3 前端简化落地方案（职责保留 + 逻辑分散）

前端未单独抽离 Presenter 物理层，但完整保留其'展示适配、解耦业务与 UI'的核心职责，采用'轻量工具函数 + 逻辑分散至对应层'的落地方式，根据展示适配的复杂度，分为三种实现场景，均以'拦截池'业务为例做代码示例。

场景 1：轻量展示适配（主流）→ 直接嵌入 UI 层 / 控制层

适用于单组件专属、逻辑简单的展示适配（如字段格式化、简单状态判断），直接在 UI 层（Vue / React 组件）或控制层中实现，是前端最常用的方式，代码示例（Vue 组件 UI 层实现）。

<!-- components/InterceptionRuleList.vue 拦截池规则列表组件 -->
<template>
  <el-table :data="viewRuleList" border stripe>
    <el-table-column prop="id" label="规则 ID" width="100"/>
    <el-table-column prop="name" label="规则名称">
      <!-- 展示适配：根据是否过期标红 -->
      <template #default="scope">
        <span :class="{ 'text-red-500': scope.row.isExpired }">{{ scope.row.name }}</span>
      </template>
    </el-table-column>
    <!-- 展示适配：将原始条件字符串格式化为易读文本 -->
    <el-table-column label="规则条件">
      <template #default="scope">{{ formatCondition(scope.row.condition) }}</template>
    </el-table-column>
    <el-table-column prop="createTimeFormat" label="创建时间" width="180"/>
  </el-table>
</template>

<script setup lang="ts">
import { ref, computed } from 'vue';
import { useInterceptionPoolController } from '../controller';

// 从控制层获取 UseCase 处理后的通用业务 Model
const { ruleList } = useInterceptionPoolController('default');

// Presenter 层核心职责：Model → View Model（轻量展示适配，嵌入 UI 层）
// 1. 时间戳格式化：业务 Model 中是时间戳，View Model 中是格式化后的字符串
const viewRuleList = computed(() =>
  ruleList.value.map(rule => ({
    ...rule,
    // 继承通用业务 Model 的所有字段
    createTimeFormat: new Date(rule.createTime).toLocaleString('zh-CN') // 展示专属字段
  }))
);

// 2. 规则条件格式化：将后端原始字符串转换为易读文本（纯展示逻辑，与业务无关）
const formatCondition = (condition: string): string => {
  if (!condition) return '无规则条件';
  // 仅做展示格式转换，不涉及任何业务逻辑判断
  return condition.replace(/&/g, '，').replace(/=/g, '：');
};
</script>

<style scoped>
.text-red-500 { color: #ef4444; }
</style>

场景 2：复杂展示适配 → 抽离独立 Presenter 工具函数

适用于适配逻辑复杂、需多次复用的场景（如多组件展示同一类数据、复杂的展示字段拼接 / 计算），不单独建层，而是在对应模块下创建轻量 Presenter 工具函数，实现展示适配逻辑的复用。

步骤 1：创建模块内 Presenter 工具函数（非物理层）

// interception-pool/presenter-utils.ts 仅做展示适配的工具函数（Presenter 层职责）
import { InterceptionRuleModel } from '../model/interception-pool';

// 定义组件专属的 View Model（仅服务于渲染，无任何业务字段）
export interface InterceptionRuleViewModel {
  id: string;
  name: string;
  nameTag: string; // 展示专属：规则名称 + 过期标签（如'测试规则 [已过期]'）
  conditionDesc: string; // 展示专属：格式化后的规则条件
  createTime: string; // 展示专属：格式化后的创建时间
  operateBtnStatus: boolean; // 展示专属：操作按钮是否禁用（根据过期状态）
}

// Presenter 核心方法：Model → View Model（纯展示适配，无业务逻辑）
export const mapRuleModelToViewModel = (model: InterceptionRuleModel): InterceptionRuleViewModel => {
  // 展示适配 1：名称拼接过期标签
  const nameTag = model.isExpired ? `${model.name}[已过期]` : model.name;
  // 展示适配 2：规则条件格式化
  const conditionDesc = model.condition ? model.condition.replace(/&/g, '，').replace(/=/g, '：') : '无规则条件';
  // 展示适配 3：格式化创建时间
  const createTime = new Date(model.createTime).toLocaleString('zh-CN');
  // 展示适配 4：根据过期状态判断操作按钮是否禁用
  const operateBtnStatus = model.isExpired;

  return {
    id: model.id,
    name: model.name,
    nameTag,
    conditionDesc,
    createTime,
    operateBtnStatus
  };
};

步骤 2：UI 层引入工具函数实现渲染

<!-- components/InterceptionRuleList.vue -->
<template>
  <el-table :data="viewRuleList" border stripe>
    <el-table-column prop="nameTag" label="规则名称"/>
    <el-table-column prop="conditionDesc" label="规则条件"/>
    <el-table-column prop="createTime" label="创建时间"/>
    <el-table-column label="操作">
      <template #default="scope">
        <el-button :disabled="scope.row.operateBtnStatus" @click="handleEdit(scope.row.id)">编辑</el-button>
      </template>
    </el-table-column>
  </el-table>
</template>

<script setup lang="ts">
import { ref, computed } from 'vue';
import { useInterceptionPoolController } from '../controller';

// 引入 Presenter 工具函数
import { mapRuleModelToViewModel, InterceptionRuleViewModel } from './presenter-utils';

const { ruleList } = useInterceptionPoolController('default');

// 统一做 Model → View Model 的转换
const viewRuleList = computed<InterceptionRuleViewModel[]>(() =>
  ruleList.value.map(model => mapRuleModelToViewModel(model))
);
</script>

步骤 3：跨模块通用展示适配 → 抽离公共 Presenter 工具

适用于全项目多模块复用的展示适配逻辑（如时间格式化、状态码转中文、金额单位转换），可在 src/common/ 下创建公共 Presenter 工具，实现全局复用，本质仍是无物理层的工具化实现。

代码示例（全局公共 Presenter 工具）

// src/common/presenter/format-utils.ts 全局展示适配工具

/**
 * 时间戳格式化（全局通用展示适配）
 * @param timestamp 时间戳（业务 Model 通用字段）
 * @param format 格式化类型
 * @returns 格式化后的时间字符串（View Model 展示字段）
 */
export const formatTimestamp = (
  timestamp: number,
  format: 'date' | 'datetime' = 'datetime'
): string => {
  if (!timestamp) return '-';
  const date = new Date(timestamp);
  const y = date.getFullYear();
  const m = (date.getMonth() + 1).toString().padStart(2, '0');
  const d = date.getDate().toString().padStart(2, '0');
  const h = date.getHours().toString().padStart(2, '0');
  const min = date.getMinutes().toString().padStart(2, '0');
  return format === 'date' ? `${y}-${m}-${d}` : `${y}-${m}-${d}${h}:${min}`;
};

/**
 * 布尔值状态转中文（全局通用展示适配）
 * @param status 布尔值（业务 Model 通用字段）
 * @param trueText 为 true 时的展示文本
 * @param falseText 为 false 时的展示文本
 * @returns 中文状态（View Model 展示字段）
 */
export const formatBoolStatus = (status: boolean, trueText: string, falseText: string): string => {
  return status ? trueText : falseText;
};

4.4.4 简化实现的核心原则与价值

1. 核心原则：保留职责，不硬套层级

前端简化实现 Presenter 层的核心是'不追求物理层的抽离，只保证职责的独立与解耦'，需遵循三个原则：

• 展示适配与业务逻辑完全分离：Presenter 层的所有代码仅做展示格式转换，不包含任何业务判断 / 规则处理（如不能在 Presenter 中过滤'过期规则'，该逻辑属于 UseCase 层业务逻辑）
• 适配逻辑贴近 UI：展示适配的代码尽可能在'使用它的 UI 层 / 组件'附近，减少跨层跳转的维护成本
• 单一职责：每个 Presenter 工具函数仅负责一类数据的展示转换，避免逻辑混杂

2. 核心价值

即使未单独抽离物理层，Presenter 层的简化实现仍能发挥 Clean Architecture 赋予的核心价值。

• 解耦业务与展示：业务逻辑（UseCase 层）仅维护通用 Model，无需关心 UI 如何展示，UI 层修改展示格式时，不影响任何业务代码
• 降低维护成本：展示适配逻辑集中管理（或贴近 UI），修改展示需求（如时间格式从 YYYY-MM-DD 改为 MM/DD/YYYY）时，仅需调整 Presenter 适配逻辑，不涉及组件其他代码
• 提升组件复用性：通用业务 Model 可通过不同的 Presenter 适配逻辑，在不同组件中展示为不同的 View Model，实现'一份业务数据，多端 / 多组件不同展示'

五、总结

通过 Vue / React + Clean Architecture 方案落地实现了：

1. 业务 - 框架解耦：实现核心业务逻辑与 Vue / React 框架的解耦，确保技术栈切换时实现 100% 代码复用
2. 维护效率提升：业务规则变更仅需修改领域层代码，维护时间大幅缩短
3. 跨端复用率：PC 后台的拦截池逻辑在小程序中 100% 复用，新终端开发周期显著压缩
4. 测试覆盖率：核心业务逻辑单元测试覆盖率提高，线上 bug 率明显下降

该方案的核心价值是'适配业务复杂度'——既避免了'照搬后端架构'的过度设计，又通过分层解耦解决了大型前端系统的维护痛点，为长期迭代提供了坚实的架构基础。