# eshop-class2-group1

**Repository Path**: grade24-fullstack-class2/eshop-class2-group1

## Basic Information

- **Project Name**: eshop-class2-group1
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: main
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 1
- **Forks**: 2
- **Created**: 2026-07-21
- **Last Updated**: 2026-07-24

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 电子商城（E-Shop）暑期企业级综合项目实战

> 班级：____ 组号：____ 组名：____

## 一、项目简介

本项目为软件技术专业暑期企业级综合项目实战，目标是以小组协作方式，在 **4 周** 内完成一个功能完整、可演示、可部署的 **电子商城系统**，全程模拟企业真实研发流程：需求分析 → 系统设计 → 编码实现 → 测试 → 部署 → 验收答辩。

## 二、小组成员与分工（模块负责制）

本项目采用 **模块负责制**：不按前后端分工，每人认领业务模块，独立负责该模块的 **数据库表 + 后端接口 + 前端页面** 完整链路。

| 姓名 | 学号 | 角色 | 负责模块（全栈） |
|------|------|------|------------------|
|      |      | 组长/架构员 | 项目脚手架、鉴权基础设施与管线装配、公共组件、集成联调 + 1 个小模块；登录业务归 Identity 负责人 |
|      |      | 模块负责人 | 商品模块（分类/列表/搜索/详情 + 后台商品管理）+ X01 收藏与浏览历史 |
|      |      | 模块负责人 | 订单 + 支付模块（含后台订单管理） |
|      |      | 模块负责人 | 用户 + 购物车模块（含后台用户管理） |
|      |      | 模块负责人 | 测试 + 部署 + X02 后台操作日志 + C09 数据统计看板 |

> 分工规则详见 `docs/00-项目要求/项目要求.md` 第三节，模块难度权重与考核挂钩。
> 4 人组时，测试与部署职责分摊到各模块负责人，选做功能由认领者负责。

## 三、技术栈（已冻结基线）

| 分层 | 技术选型 | 版本 |
|------|----------|------|
| Web / 桌面端 | Vue 3 + TypeScript（strict）+ Vite + PWA；Tauri 2 桌面薄壳 | Vue 3.x / Tauri 2.x |
| 后端 | .NET 10 LTS + ASP.NET Core 10 + EF Core 10 + Npgsql | 10.x |
| 数据库 | PostgreSQL | 18.4 |
| 部署 | Nginx 静态资源与反向代理 + ASP.NET Core API 服务 + PostgreSQL | 按部署环境锁定 |

> 表中版本表示架构基线。可复现构建所用的精确版本分别以 `global.json`、`packageManager`、依赖锁文件和 `Directory.Packages.props` 为准；Docker 可作为环境封装手段，但不是本项目的通用硬要求。

### 架构与协作基线

- [系统架构设计](docs/02-设计文档/系统架构设计.md)
- [技术栈与多 Agent 协作约束](docs/02-设计文档/技术栈与多Agent协作约束.md)
- [第一天方案对比与实施计划](docs/02-设计文档/第一天方案对比与实施计划.md)
- [第二天执行计划](docs/02-设计文档/第二天执行计划.md)
- [后续实施计划（Day 3～Day 20）](docs/02-设计文档/后续实施计划.md)

## 四、仓库目标目录结构

以下仅为方便浏览的目录摘要；尚未创建的代码目录不代表当前已经完成实现。可执行的完整目录、文件所有权和单写者清单以[技术栈与多 Agent 协作约束](docs/02-设计文档/技术栈与多Agent协作约束.md)第三、五节为唯一事实源，本摘要不得用于推断未列文件可由任意 Agent 修改。

```
├── README.md                              # 项目入口
├── global.json                            # 从仓库根锁定 .NET SDK 精确版本
├── contracts/
│   └── openapi/
│       ├── eshop-v1.yaml                  # 聚合后的 API v1 契约
│       └── modules/                       # 各业务模块的 OpenAPI 片段
├── frontend/
│   ├── src/
│   │   ├── app/                           # 启动、根路由、布局与组合入口
│   │   ├── modules/                       # 按业务模块组织的垂直切片
│   │   ├── platform/                      # Web / Tauri 平台端口与适配器
│   │   └── shared/                        # 经评审的跨模块通用能力
│   ├── src-tauri/                         # Tauri 2 桌面薄壳与权限配置
│   └── tests/                             # 前端集成与端到端测试
├── backend/
│   ├── Directory.Packages.props           # NuGet 依赖集中版本
│   ├── EShop.slnx
│   ├── src/
│   │   ├── EShop.Api/                     # 组合根与 HTTP 宿主
│   │   ├── EShop.Contracts/               # 跨模块应用契约
│   │   ├── EShop.SharedKernel/            # 最小共享内核
│   │   ├── EShop.Infrastructure/           # DbContext 与外部系统适配器
│   │   └── EShop.Modules.<Module>/        # Identity、Catalog、Cart 等模块项目
│   └── tests/                             # 后端单元与集成测试
├── docs/
│   ├── 00-项目要求/                       # 教师发布，勿改
│   ├── 01-需求文档/
│   ├── 02-设计文档/
│   ├── 03-测试文档/
│   ├── 04-会议记录/
│   └── 05-总结答辩/
└── reports/
    ├── daily/                             # 每人每日一份
    └── weekly/                            # 每组每周一份
```

## 五、关键时间节点（4 周）

| 阶段 | 时间 | 交付物 |
|------|------|--------|
| 第 1 周 | 需求与设计 | 需求规格说明书、架构/数据库/接口设计 |
| 第 2 周 | 核心功能开发 | 用户、商品模块可演示 |
| 第 3 周 | 完整功能开发 | 购物车、订单、支付（模拟）模块可演示；选做功能与挑战模块开发 |
| 第 4 周 | 测试、部署与答辩 | 测试报告、挑战模块压测/边界验证、部署上线、总结报告、答辩 |

## 六、Git 协作规范

1. `develop` 是默认且唯一的代码开发集成线，也是当前实现及其正式设计、接口与数据库文档的权威查看点。功能或修复任务需要隔离时，从最新 `develop` 创建 `feature/<module>-<item>` 或 `fix/<module>-<item>` 分支，并且只合并回 `develop`；除非用户另有明确说明，不在其他分支开展开发。
2. `main` 默认仅接收独立的文档、报告等非开发项；代码、迁移、构建配置和依赖变更不得以“文档提交”名义进入 `main`。本次首日文档基线在 `main` 形成一个提交后，以保留同一提交历史的 fast-forward 同步到尚未分叉的 `develop`；禁止手工复制或制造两份内容相同、哈希不同的提交。此后，随功能或修复变化的契约和设计文档与代码一同进入 `develop`，独立报告仍只进入 `main`。最终发布/验收若需把通过门禁的 `develop` 版本晋升到 `main`，属于特殊操作，必须先取得用户明确指示并经 Review，禁止开发者直接 push 代码。
3. 一个完整功能或一次 BUG 修复在相关测试通过、达到完成定义时必须立即提交；**一次完整修订记录就是一个提交**，其中包含该修订所需的实现、迁移、生成物、文档和测试，不得混入无关功能、顺手重构或其他成员的改动。任务分支若有协作中间提交，合入 `develop` 前必须整理为一个最终提交。
4. 测试确认完成后，必须在用户下一轮开始不相关改进之前先推送该完成提交；推送前重新确认分支、精确暂存路径、测试结果和远端差异。
5. 被日报、周报、任务单或 Review 引用的远端 `feature/*`、`fix/*` 与集成分支，在课程验收及可能复验结束前不得删除、强推或改写；过程材料必须记录真实分支和 commit hash。即使集成人为 `develop` 生成单一最终提交，原作者的可审计提交仍须在这些远端引用中保留。
6. 提交信息格式：`<type>: <描述>`，type 取值：`feat` `fix` `refactor` `docs` `test` `chore`。
7. **每人每天至少一次有效提交**，提交记录将作为个人考核依据；不得通过改写作者、时间或拆分空提交制造过程证据。
8. **交叉 Code Review**：每个功能或修复分支须由相邻模块负责人审查并留痕，再由组长或指定集成人合入 `develop`。

## 七、如何开始

1. 全组阅读 `docs/00-项目要求/` 下的全部文档。
2. 完成分工表、确定技术栈并填入本文件。
3. 按 `docs/01-需求文档/` 模板开始编写需求文档。
4. 每天下班前提交个人日报到 `reports/daily/`。