# Kế hoạch Chuyển đổi và Rollback Kiến trúc (Migration & Rollback Plan)

## 1. Tình trạng hiện tại
- Phân hệ `Projects` đang sử dụng kiến trúc cũ (dùng `ProjectManagementService` gọi trực tiếp `PostgresClient`).
- Cơ sở dữ liệu: Dữ liệu hiện tại đang nằm chung hoặc chưa tách biệt schema rõ ràng.

## 2. Phương pháp Chuyển đổi (Migration Strategy)
Chúng ta sẽ áp dụng chiến lược **Strangler Fig Pattern** (Trồng cây si) kết hợp **Git Branching**:
- Không đập bỏ code cũ ngay lập tức.
- Tạo nhánh git mới (hoặc commit riêng biệt) cho bản Refactor.
- Các endpoint API mới (áp dụng CQRS) sẽ được mount song song với API cũ bằng tiền tố (ví dụ: `/v2/erp/projects`) hoặc thay thế an toàn nếu có unit test.

## 3. Quy trình Backup trước khi can thiệp
Trước khi sửa bất kỳ file nào trong `app/modules/projects`, các lệnh sau phải được thực thi:

```bash
# 1. Lưu lại trạng thái git hiện tại (Backup code)
git add .
git commit -m "chore: backup before CQRS refactoring"

# 2. Tạo nhánh làm việc mới
git checkout -b refactor/modular-monolith-projects

# 3. Dump database hiện tại (Backup dữ liệu nếu cần)
# pg_dump -U postgres -d dscons > dscons_backup_before_refactor.sql
```

## 4. Phương án Rollback (Khôi phục)
Nếu kiến trúc mới gặp lỗi nghiêm trọng (Critical Bug) trên môi trường Staging/Production hoặc không qua được Regression Tests:

**Cách 1: Khôi phục bằng Git (Code Rollback)**
```bash
# Huỷ bỏ mọi thay đổi chưa commit
git restore .

# Trở về nhánh chính và xoá nhánh lỗi
git checkout main
git branch -D refactor/modular-monolith-projects
```

**Cách 2: Khôi phục Database (Nếu có Schema changes bị lỗi)**
```sql
-- Chạy script hạ cấp DB bằng Alembic (Nếu có)
-- alembic downgrade -1

-- Hoặc xoá schema mới nếu nó làm hỏng dữ liệu
DROP SCHEMA projects_new CASCADE;
```

## 5. Chốt chặn An toàn (Quality Gates)
Việc chuyển đổi chỉ được tính là hoàn tất (Done) khi:
1. Qua được 100% `pytest` tự động (như yêu cầu tại Core Law #2).
2. API Docs được cập nhật tương ứng với Swagger.
3. Không làm hỏng các module khác đang phụ thuộc vào `projects`.