1cd5d3bdef
主要更新： 1. 后端核心底座完成 (M1-M6)： - 健康检查、指标监控、分布式锁 - 事件总线、队列系统、事务管理 - 安全守卫、多租户隔离、存储适配器 - 审计日志、配置管理、多语言支持 2. 前端迁移到 Ant Design Vue： - 从 Element Plus 迁移到 Ant Design Vue - 完善 system 模块 (role/menu/dept) - 修复依赖和配置问题 3. 文档完善： - AI 开发工作流文档 - 架构约束和开发规范 - 项目进度跟踪 4. 其他改进： - 修复编译错误和类型问题 - 完善测试用例 - 优化项目结构
5.2 KiB
5.2 KiB
架构约束规则
🏗️ 分层架构
┌─────────────────┐
│ App │ ← 业务开发层（用户自定义业务模块）
│ (用户业务) │ 电商、CRM、ERP等具体业务逻辑
└─────────────────┘
↓
┌─────────────────┐
│ Common │ ← 框架通用服务层（企业级通用功能）
│ (框架通用服务) │ 用户管理、权限管理、菜单管理
└─────────────────┘ 文件上传、通知服务、系统设置
↓ 数据字典、缓存服务、队列服务
┌─────────────────┐
│ Core │ ← 核心基础设施层（底层基础设施）
│ (基础设施) │ 认证核心、数据库核心、验证核心
└─────────────────┘ HTTP核心、缓存核心、队列核心
↓
┌─────────────────┐
│ Vendor │ ← 第三方服务适配层
│ (外部集成) │ 存储、支付、通信、云服务适配
└─────────────────┘
┌─────────────────┐
│ Addons │ ← 插件扩展层（可插拔功能模块）
│ (插件扩展) │ 扩展框架功能，不影响核心稳定性
└─────────────────┘
┌─────────────────┐
│ Test │ ← 测试代码层（独立测试模块）
│ (测试代码) │ 单元测试、集成测试、E2E测试
└─────────────────┘
📋 依赖约束规则
1. Core 层（最底层）
- ✅ 允许依赖：无（最底层基础设施）
- ❌ 禁止依赖：Common、App、Vendor 层
- 📁 位置：
src/core/ - 🎯 职责：提供最基础的抽象和接口
2. Vendor 层（第三方适配）
- ✅ 允许依赖：Core 层
- ❌ 禁止依赖：Common、App 层
- 📁 位置：
src/vendor/ - 🎯 职责：第三方服务适配，实现 Core 层抽象
3. Common 层（通用服务）
- ✅ 允许依赖：Core 层
- ❌ 禁止依赖：App、Vendor 层
- 📁 位置：
src/common/ - 🎯 职责：企业级通用功能，基于 Core 层构建
4. App 层（业务应用）
- ✅ 允许依赖：Common、Core 层
- ❌ 禁止依赖：Vendor 层（通过 Common 层抽象）
- 📁 位置：
src/app/ - 🎯 职责：具体业务逻辑实现
5. Test 层（测试代码）
- ✅ 允许依赖：所有层（测试需要）
- 📁 位置：
test/（项目根目录） - ❌ 禁止位置：
src/目录下 - 🎯 职责：测试所有层的功能
🚫 禁止的依赖关系
// ❌ 错误：Common 层依赖 App 层
// src/common/auth/auth.service.ts
import { AppService } from '../../app/app.service'; // 禁止！
// ❌ 错误：Core 层依赖 Common 层
// src/core/database/database.service.ts
import { UserService } from '../../common/user/user.service'; // 禁止！
// ❌ 错误：App 层直接依赖 Vendor 层
// src/app/payment/payment.service.ts
import { AlipayProvider } from '../../vendor/payment/alipay.provider'; // 禁止！
// ❌ 错误：在 src 目录下创建测试代码
// src/test/test.service.ts - 禁止！
✅ 正确的依赖关系
// ✅ 正确：Common 层依赖 Core 层
// src/common/auth/auth.service.ts
import { JwtService } from '../../core/auth/jwt.service';
// ✅ 正确：App 层依赖 Common 层
// src/app/user/user.controller.ts
import { AuthService } from '../../common/auth/auth.service';
// ✅ 正确：Vendor 层依赖 Core 层
// src/vendor/payment/alipay.provider.ts
import { PaymentProvider } from '../../core/payment/payment.provider';
// ✅ 正确：测试代码依赖所有层
// test/auth.test.ts
import { AuthService } from '../src/common/auth/auth.service';
🔧 ESLint 规则
项目已配置严格的 ESLint 规则来强制执行这些约束：
- 分层依赖检查：自动检测违反依赖方向的导入
- 测试代码位置检查：禁止在 src 目录下创建测试代码
- 路径别名检查：强制使用相对路径，避免路径别名
- 内部实现检查：禁止依赖其他模块的内部实现
📝 开发建议
- 设计时先确定层级：新功能应该放在哪一层？
- 依赖时检查方向：确保依赖关系符合架构约束
- 测试代码统一管理：所有测试代码放在
test/目录 - 定期运行 ESLint：
npm run lint检查架构约束 - 代码审查时关注架构：确保新代码符合分层原则
🚨 常见错误
- 在 Core 层导入业务逻辑
- Common 层直接调用第三方服务
- App 层绕过 Common 层直接使用 Vendor
- 测试代码放在 src 目录下
- 使用绝对路径或路径别名导入
遵循这些约束规则，可以确保 WWJCloud 的架构清晰、依赖关系正确，为未来的微服务拆分奠定坚实基础。