# 🚀 نقشه‌راه حذف Gateway ها و انتقال به CMS

> تاریخ: ۳۰ ژانویه ۲۰۲۶

## 🎯 هدف کلی

حذف پیچیدگی معماری با انتقال همه سرویس‌های Gateway به CMS microservice. این کار مزایای زیر داره:

- **Performance بهتر**: حذف network hop اضافی
- **Simplicity**: کمتر dependency، آسان‌تر maintenance
- **Cost**: کمتر resource و deployment complexity
- **Modularity**: ساختار ماژولار در CMS که بعداً قابل جداسازی باشه

---

## 📊 وضعیت موجود

### BackOffice.BFF - Services List ✅

| Service | Proto | وضعیت در CMS | Type |
|---------|-------|-------------|------|
| AppVersionService | ✅ | ✅ موجود | Direct |
| CategoryService | ✅ | ✅ موجود | Direct |
| ClubMembershipService | ✅ | ✅ موجود | Direct |
| CommissionService | ✅ | ✅ موجود | Direct |
| ConfigurationService | ✅ | ✅ موجود | Direct |
| DiscountCategoryService | ✅ | ✅ موجود | Direct |
| DiscountOrderService | ✅ | ✅ موجود | Direct |
| DiscountProductService | ✅ | ✅ موجود | Direct |
| DiscountShoppingCartService | ✅ | ✅ موجود | Direct |
| HealthService | ✅ | ❌ ندارد | **New** |
| InventoryService | ✅ | ✅ موجود | Direct |
| ManualPaymentService | ✅ | ✅ موجود | Direct |
| NetworkMembershipService | ✅ | ❌ ندارد | **New** |
| OtpService | ✅ | ✅ موجود (OtpTokenService) | Direct |
| PackageService | ✅ | ✅ موجود | Direct |
| ProductTagService | ✅ | ✅ موجود | Direct |
| ProductsService | ✅ | ✅ موجود | Direct |
| PublicMessageService | ✅ | ✅ موجود | Direct |
| RoleService | ✅ | ✅ موجود | Direct |
| TagService | ✅ | ✅ موجود | Direct |
| UserAddressService | ✅ | ✅ موجود | Direct |
| UserOrderService | ✅ | ✅ موجود | Direct |
| UserRoleService | ✅ | ✅ موجود | Direct |
| UserService | ✅ | ✅ موجود | Direct |

**خلاصه BackOffice.BFF**: 24 سرویس - 22 موجود در CMS، 2 نیاز به ایجاد

---

### FrontOffice.BFF - Services List 🔄

| Service | Proto | وضعیت در CMS | Type | توضیحات |
|---------|-------|-------------|------|---------|
| AppVersionGrpcService | ✅ | ✅ موجود | Direct | |
| CategoriesService | ✅ | ✅ موجود | Direct | |
| CityService | ✅ | ✅ موجود | Direct | |
| ClubMembershipService | ✅ | ✅ موجود | Direct | |
| ClubMembershipGrpcService | ✅ | ✅ موجود | Direct | |
| CommissionService | ✅ | ✅ موجود | Direct | |
| ConfigurationGrpcService | ✅ | ✅ موجود | Direct | |
| DiscountShopService | ✅ | ✅ موجود (partial) | **Extend** | نیاز ترکیب با DiscountProduct/Category/Cart |
| NetworkMembershipService | ✅ | ❌ ندارد | **New** | |
| PackageService | ✅ | ✅ موجود | Direct | |
| ProductsService | ✅ | ✅ موجود | Direct | |
| ShopingCartService | ✅ | ✅ موجود (UserCartsService) | Direct | |
| TransactionService | ✅ | ✅ موجود (TransactionsService) | Direct | |
| UserAddressService | ✅ | ✅ موجود | Direct | |
| UserOrderService | ✅ | ✅ موجود | Direct | |
| UserService | ✅ | ✅ موجود | **Customer** | نیاز Customer-specific logic |
| UserWalletService | ✅ | ✅ موجود | Direct | |

**خلاصه FrontOffice.BFF**: 17 سرویس - 15 موجود، 1 نیاز ایجاد، 1 نیاز extend

---

## 🛠️ Migration Strategy

### Phase 1: سرویس‌های جدید در CMS

#### 1.1 HealthService (BackOffice.BFF → CMS)

**مسیر**: `CMS/src/CMSMicroservice.WebApi/Services/HealthService.cs`

```csharp
// الگوی پیاده‌سازی
public class HealthService : HealthContract.HealthContractBase
{
    public override async Task<HealthCheckResponse> CheckHealth(Empty request, ServerCallContext context)
    {
        // Logic: Database connectivity, external services, etc.
        return new HealthCheckResponse { ... };
    }
}
```

**Dependencies**: 
- Proto: `CMS/src/CMSMicroservice.Protobuf/Protos/Health.proto`
- Application Layer: `CMS/src/CMSMicroservice.Application/HealthCQ/`

#### 1.2 NetworkMembershipService (Both → CMS)

**مسیر**: `CMS/src/CMSMicroservice.WebApi/Services/NetworkMembershipService.cs`

```csharp
public class NetworkMembershipService : NetworkMembershipContract.NetworkMembershipContractBase
{
    // Binary Tree Management
    // User Placement Logic  
    // Network Statistics
}
```

**Dependencies**:
- Proto: `CMS/src/CMSMicroservice.Protobuf/Protos/NetworkMembership.proto`
- Application: `CMS/src/CMSMicroservice.Application/NetworkMembershipCQ/`
- Domain: احتمالاً موجوده، نیاز بررسی

---

### Phase 2: ماژولار کردن در CMS

#### ساختار پیشنهادی:

```
CMS/src/CMSMicroservice.WebApi/Services/
├── Core/              # سرویس‌های پایه
│   ├── HealthService.cs
│   ├── ConfigurationService.cs
│   └── AppVersionService.cs
├── UserManagement/    # مدیریت کاربران
│   ├── UserService.cs
│   ├── UserRoleService.cs
│   ├── UserAddressService.cs
│   ├── UserOrderService.cs
│   ├── UserWalletService.cs
│   ├── UserCartsService.cs
│   └── OtpTokenService.cs
├── ProductCatalog/    # کاتالوگ محصولات
│   ├── ProductsService.cs
│   ├── CategoryService.cs
│   ├── ProductTagService.cs
│   ├── TagService.cs
│   ├── ProductGalleriesService.cs
│   └── ProductImagesService.cs
├── DiscountShop/      # فروشگاه تخفیف
│   ├── DiscountProductService.cs
│   ├── DiscountCategoryService.cs
│   ├── DiscountOrderService.cs
│   └── DiscountShoppingCartService.cs
├── Commission/        # کمیسیون و شبکه
│   ├── CommissionService.cs
│   ├── NetworkMembershipService.cs    # جدید
│   └── ClubMembershipService.cs
├── Inventory/         # انبارداری
│   └── InventoryService.cs
├── Payment/           # پرداخت
│   ├── ManualPaymentService.cs
│   ├── TransactionsService.cs
│   └── UserWalletChangeLogService.cs
└── Content/           # محتوا
    ├── PublicMessageService.cs
    ├── CityService.cs
    └── PackageService.cs
```

---

### Phase 3: Proto Files Management

#### موجود در CMS که نیاز تغییر نداره:
- `Category.proto` ✅
- `Commission.proto` ✅  
- `Products.proto` ✅
- `User.proto` ✅
- `Configuration.proto` ✅
- ... (بیشتر protos موجودن)

#### نیاز به اضافه کردن:
1. **`Health.proto`** - برای health check endpoints
2. **`NetworkMembership.proto`** - اگر موجود نیست

#### Proto files در Gateway ها که نیاز consolidation دارن:
```
BackOffice.BFF/src/Protobufs/ → CMS/src/CMSMicroservice.Protobuf/
FrontOffice.BFF/src/Protobufs/ → CMS/src/CMSMicroservice.Protobuf/
```

---

### Phase 4: Application Layer Integration  

#### BackOffice.BFF Application CQ → CMS Application

```
BackOffice.BFF/src/BackOffice.BFF.Application/
├── CommissionCQ/ → CMS/Application/CommissionCQ/
├── ProductsCQ/ → CMS/Application/ProductsCQ/
├── UserCQ/ → CMS/Application/UserCQ/
└── ...
```

**Strategy**: 
- مرج کردن Commands/Queries مشابه
- حفظ Business Logic موجود در CMS
- اضافه کردن Gateway-specific logic به CMS

#### مثال: CommissionCQ Migration

**BackOffice.BFF موجود**:
- `TriggerWeeklyCalculationCommand`
- `GetUserCommissionPayoutsQuery`  
- `ApproveWithdrawalCommand`

**CMS موجود**:
- `CalculateWeeklyCommissionCommand`
- `GetCommissionPayoutsQuery`

**Strategy**: ترکیب و تکمیل در CMS

---

### Phase 5: Client-Side Changes

#### BackOffice UI Changes

```csharp
// Before (BackOffice → BackOffice.BFF)
services.AddGrpcClient<UserContract.UserContractClient>(options =>
{
    options.Address = new Uri("https://backoffice-bff:443");
});

// After (BackOffice → CMS)
services.AddGrpcClient<UserContract.UserContractClient>(options =>
{
    options.Address = new Uri("https://cms:443");  
});
```

#### FrontOffice UI Changes

```csharp
// Before (FrontOffice → FrontOffice.BFF)
services.AddGrpcClient<ProductsContract.ProductsContractClient>(options =>
{
    options.Address = new Uri("https://frontoffice-bff:443");
});

// After (FrontOffice → CMS)  
services.AddGrpcClient<ProductsContract.ProductsContractClient>(options =>
{
    options.Address = new Uri("https://cms:443");
});
```

---

## 📋 Implementation Plan

### Week 1: Analysis & Proto Consolidation
- [ ] **Day 1**: تحلیل کامل Dependencies بین Gateway ها و CMS
- [ ] **Day 2**: Merge کردن Proto files مشابه
- [ ] **Day 3**: شناسایی Business Logic های unique در Gateway ها  
- [ ] **Day 4**: ایجاد migration scripts برای Application Layer
- [ ] **Day 5**: طراحی namespace جدید در CMS

### Week 2: Core Services Migration  
- [ ] **Day 1-2**: پیاده‌سازی HealthService و NetworkMembershipService در CMS
- [ ] **Day 3-4**: Migration UserService (با Customer-specific logic)
- [ ] **Day 5**: تست و validation سرویس‌های جدید

### Week 3: Application Layer Migration
- [ ] **Day 1-2**: انتقال CommissionCQ از Gateway ها به CMS
- [ ] **Day 3**: انتقال ProductsCQ
- [ ] **Day 4**: انتقال UserCQ  
- [ ] **Day 5**: انتقال باقی CQ modules

### Week 4: Client Integration & Testing
- [ ] **Day 1-2**: تغییر BackOffice client configuration
- [ ] **Day 3**: تغییر FrontOffice client configuration  
- [ ] **Day 4**: End-to-end testing
- [ ] **Day 5**: Performance testing و optimization

### Week 5: Cleanup & Documentation  
- [ ] **Day 1-2**: حذف Gateway projects از repository
- [ ] **Day 3**: بروزرسانی Docker compose و K8s configs
- [ ] **Day 4**: بروزرسانی deployment scripts
- [ ] **Day 5**: مستندسازی نهایی

---

## ⚠️ Risks & Considerations

### High Risk
1. **Breaking Changes**: تغییر endpoint URLs در client ها
2. **Business Logic Loss**: احتمال از دست رفتن logic خاص Gateway ها
3. **Performance Impact**: CMS ممکنه bottleneck بشه

### Medium Risk  
1. **Proto Conflicts**: تداخل message names در Proto files
2. **Authorization**: تفاوت در Authorization logic بین Gateway ها
3. **Testing Complexity**: نیاز تست کامل همه endpoints

### Mitigation Strategies
- **Gradual Migration**: یک سرویس در هر مرحله
- **Feature Flags**: قابلیت switch بین Gateway و CMS
- **Comprehensive Testing**: Unit + Integration + End-to-end
- **Rollback Plan**: امکان بازگشت سریع در صورت مشکل

---

## 🎯 Success Metrics

### Performance
- [ ] Response time کاهش یافته (حذف network hop)
- [ ] Throughput افزایش یافته
- [ ] Resource usage بهینه شده

### Architecture  
- [ ] کد duplication کاهش یافته
- [ ] Maintenance complexity کمتر شده
- [ ] Deployment pipeline ساده‌تر شده

### Developer Experience
- [ ] کمتر project برای کار روی یک feature
- [ ] Debug و troubleshoot آسان‌تر
- [ ] Documentation کامل و به‌روز

---

## 📝 Notes

### Critical Dependencies
- همه Proto messages باید compatible باشن
- Authorization و Authentication logic حفظ بشه  
- Database migration نیازی نیست (همون دیتابیس رو استفاده می‌کنیم)

### Future Modularity
ساختار ماژولار پیشنهادی باعث میشه بعداً بتونیم:
- هر ماژول رو به microservice جداگانه تبدیل کنیم
- Load balancing بین ماژول‌ها داشته باشیم
- Feature-based deployment انجام بدیم

---

**Status**: 🔍 Analysis Complete - Ready for Implementation  
**Next Step**: شروع Phase 1 - سرویس‌های جدید  
**Owner**: Development Team  
**Estimated Duration**: 5 weeks