前端架构：构建可持续演进与AI增强的现代化体系

1. 核心理念与原则

1.1 关注点分离与可持续性

现代前端架构的核心目标不再是仅仅实现功能，而是构建一个能够持续演进、高效协作且稳定可靠的系统。这意味着我们需要将高频变化的视图层与相对稳定的核心业务逻辑彻底解耦。视图层可能因设计趋势、产品交互调整而频繁变动，而领域业务规则、计算逻辑和数据模型则具备很强的延续性。将它们分离管理，是实现长期可维护性的基石。

1.2 轻量化与降低认知负荷

在工具和模式的选择上，遵循“如无必要，勿增实体”的原则。避免引入过度复杂、概念繁重的框架或库，尤其是对于中小型项目。倡导使用原生语言特性（如Class）、设计模式和清晰的代码组织来解决状态共享与逻辑复用问题，从而降低团队的认知和上手成本，并有效控制打包体积。

1.3 强约束与AI就绪

通过建立严格的开发约束（静态类型检查、代码规范、运行时校验、测试覆盖），我们不仅提升了代码质量与人效，更重要的是为AI辅助编码（AICoding） 创造了理想环境。一个结构清晰、约束明确的代码库，使得AI能够更准确地理解意图、生成符合规范的代码，从而实现人机协作的效能飞跃。

2. 核心架构模式

2.1 整洁架构在前端的映射

关于整洁架构，详见前端整洁架构(一)：构建可持续维护的现代Web应用

借鉴整洁架构（Clean Architecture） 的思想，将系统按依赖方向划分为同心圆层，确保核心业务逻辑独立于框架、UI和外部服务。

// 依赖方向：外层依赖内层，内层对外层一无所知。
[视图层 View] -> [应用层 Application] -> [领域层 Domain] <- [基础设施层 Infra]

• 领域层 (Domain Layer): 系统的核心，项目的核心资产都在这里。

  • Model: 纯粹的业务数据模型与实体定义，包含其属性和基本验证逻辑。
  • Service: 纯粹的领域服务，包含核心的业务规则、计算逻辑和流程。此处不应有任何UI、网络、存储等具体技术细节。

• 基础设施层 (Infrastructure Layer): 实现具体技术细节，如HTTP客户端、本地存储、第三方SDK适配器等。它依赖领域层接口。

• 视图层 (View Layer): UI框架组件（如React/Vue组件）。它通过应用层或直接调用基础设施层的接口来获取数据、监听状态、触发动作。它是系统的“插件”。可以说当项目的领域层固化之后，视图层可以很轻易地去进行迁移切换。

架构分层示意：

src/
├── domain/                    # 领域层 (最核心、最稳定)
│   ├── models/               # 领域模型（实体、值对象）
│   │   ├── Product.ts
│   │   └── User.ts
│   └── services/             # 领域服务（纯业务逻辑）
│       ├── CartService.ts
│       └── PaymentService.ts
├── infra/                     # 基础设施层 (具体实现)
│   ├── network.ts           # API
│   ├── storage.ts           # 存储适配器
│   └── jump.ts              # 路由/跳转逻辑
└── view/                     # 表现层 (UI)
    ├── pages/               # 页面组件
    │   ├── PageA.vue
    │   └── PageB.vue
    └── components/          # 展示组件
        └── ComponentA.vue

2.2 面向对象领域建模

摒弃传统的、面向过程的“在组件内写业务逻辑”的方式，转而采用面向对象（OOP） 对核心业务进行建模。

// 示例：领域模型 - 购物车商品项
class CartItem {
  constructor(
    public readonly productId: string,
    public readonly name: string,
    private _quantity: number,
    public readonly price: number
  ) {}

  // 业务方法：增加数量，包含业务规则
  increaseQuantity(amount: number): void {
    if (amount <= 0) throw new Error(‘增量必须为正数’);
    if (this._quantity + amount > 99) throw new Error(‘单商品数量不能超过99’);
    this._quantity += amount;
  }

  // 计算属性：总价
  get totalPrice(): number {
    return this._quantity * this.price;
  }

  get quantity(): number { return this._quantity; }
}

// 领域服务 - 购物车
class CartService {
  private items: Map<string, CartItem> = new Map();

  addItem(product: Product, quantity: number): void {
    // 复杂的合并、校验逻辑在此处
    // 不关心这个购物车是用Vuex、Redux还是Pinia管理
  }

  calculateTotal(): number {
    // 纯粹的结算计算逻辑
    return Array.from(this.items.values()).reduce((sum, item) => sum + item.totalPrice, 0);
  }
}

2.3 轻量状态管理

Class单例与常见三方库Pinia的对比： 前端轻量级状态共享方案-Class单例

对于跨组件共享的、流程相关的或需要持久化的应用状态，采用Class单例模式提供轻量解决方案。

在合适的场景下，使用Class单例作为状态管理器具有以下优势：

• 零依赖与极致轻量：不引入任何第三方库，有助于控制应用包体积。
• 更低的认知与学习成本：对于熟悉面向对象编程的团队，使用Class比学习一个新的状态管理库更容易上手。
• 极致的灵活与控制力：代码组织方式完全由你掌控，可以轻松实现任何复杂的业务逻辑和交互模式，不受框架约定限制。
• 便于复用与独立测试：核心业务逻辑以Class形式存在，可以轻松地在非Vue环境（如Node.js服务端）中复用和进行单元测试。

2.4 代码与质量保障体系

建立从开发到验证的完整质量链条。

1. TypeScript: 提供静态类型检查，是代码文档和智能提示的基础。
2. Zod/Runtypes: 在运行时进行数据验证，特别是在API边界、用户输入处，确保类型安全从编译期延续到运行期。
3. ESLint + 自定义规则: 强制执行代码风格和最佳实践，杜绝常见的错误模式。
4. 单元测试 (Jest/Vitest): 核心领域模型（Model）和服务（Service）必须拥有高覆盖率（>90%）的单测。因为它们稳定且是系统的核心，为其编写测试 ROI（投资回报率）最高。视图组件可根据复杂度酌情采用组件测试。

3. Rules规则体系：知识沉淀与AI赋能的核心

3.1 什么是Rules？

Rules 是一个机器可读的规则集合文件（如 project-rules.md 或 .ai-rules.json），它系统地沉淀了项目的：

• 架构约束：如“领域层不得导入任何UI框架模块”。
• 代码规范：如“状态管理优先使用Class单例而非Redux”。
• 业务规则：如“优惠券计算时，折扣金额不得超过商品总价的50%”。
• 安全与合规要求：如“所有用户输入在渲染前必须经过XSS过滤”。
• 历史问题规则集：历史问题归纳总结后包含正反示例的规则集。

3.2 Rules的多重价值

1. 团队知识沉淀：将散落在文档、口口相传或代码审查中的约定集中固化，成为项目的“基本法”。
2. AICoding的精准输入：在向AI（如GitHub Copilot, Cursor, 通义灵码）提问或生成代码时，将 Rules 作为上下文的一部分输入，能极大提高生成代码的准确性和合规性。

   Prompt示例: “根据项目Rules，请为 UserProfile 领域模型创建一个包含邮箱格式验证的Zod Schema。”

3. 智能Code Review：可以将 Rules 配置给AI评审工具，自动检查提交的代码是否违反架构约束或业务规则。
4. 自动化单测生成：基于 Rules 中描述的业务规则，可以引导AI自动为领域服务生成对应的测试用例。

4. AI Coding与增长飞轮

4.1 工作流闭环

建立一个以 Rules 为核心的、AI增强的持续迭代飞轮：

[开始] -> [基于现有Rules进行AICoding] -> [人工CodeReview] -> [发现新模式/问题] -> [提炼并更新Rules] -> [飞轮再次循环]

1. 开发阶段：开发者或AI在 Rules 的约束下编写代码。
2. 审查阶段：人工Review时，不仅审查代码功能，更关注是否有 Rules 未涵盖但值得沉淀的新模式或边界情况。
3. 沉淀阶段：将审查中达成的共识、发现的优秀模式或潜在风险，反哺更新到 Rules 文件中。
4. 进化阶段：更丰富的 Rules 使得下一次AICoding和AI评审更精准、更高效。

4.2 飞轮效应

这个闭环的核心价值在于增长飞轮：

• Rules越丰富，AI的理解和生成能力就越强，人工审查也越有据可依。
• AI生成和评审越精准，代码整体质量越高，迭代速度越快，同时又能发现更多值得沉淀到Rules的经验。
• 长期运行下，项目的架构一致性和代码健康度将持续提升，而知识流失和重构成本将显著降低。

结论

本文所述的前端架构，是一种以领域为核心、以约束为保障、以AI为杠杆的现代化工程实践。它通过清晰的层次分离和面向对象建模构建了坚固的底座，通过轻量化模式降低复杂度，并通过 Rules体系 将团队经验与AI能力深度结合，形成自我增强的飞轮。这不仅是应对当前复杂应用开发挑战的方案，更是面向未来、拥抱智能化协作的必然演进方向。