mivita/dev/subdomain-optimization/README.md

Mivita Multi-Domain & Subdomain Architecture Optimization

Current Implementation Analysis

Domain Structure Overview

The mivita.care application uses a multi-domain and subdomain architecture to serve different application areas:

Main Domains & Subdomains:

1. Main Domain: mivita.care (or mivita.test in development)
2. Fixed Subdomains:
   • my.mivita.care - CRM/Customer Management System
   • in.mivita.care - Portal for customers
   • checkout.mivita.care - Checkout/Payment processing
3. Dynamic Subdomains: {shop-slug}.mivita.care - Individual user shops
4. Alternative Domain: mivita.shop - Alternative shopping domain

Current Architecture Issues

1. Subdomain Middleware Problems

File: app/Http/Middleware/Subdomain.php

Issues Identified:

• Hard-coded shop selection ('aloevera') for main domain
• Mixed responsibility (handles both dynamic shops and main domain logic)
• No proper fallback mechanism for invalid subdomains
• Configuration dependencies scattered across middleware
• Session management directly in middleware

2. Routing Complexity

Current Structure:

routes/
├── web.php          # Main entry (mostly empty)
├── main.php         # Main domain routes
├── subdomain.php    # Dynamic subdomain routes  
├── crm.php          # CRM subdomain (my.)
├── portal.php       # Portal subdomain (in.)
├── checkout.php     # Checkout subdomain (checkout.)
├── api.php          # API routes
└── utility.php      # Utility routes

Issues:

• Route duplication across files
• No clear separation of concerns
• Complex domain-based routing in multiple files
• Inconsistent middleware application

3. Configuration Management

File: .env

Current Setup:

APP_DOMAIN=mivita
APP_TLD_CARE=.test
APP_TLD_SHOP=.lshop
APP_URL_CHECKOUT=checkout.
APP_URL_CRM=my.
APP_URL_PORTAL=in.

Issues:

• Environment-dependent configuration
• No centralized domain management
• Missing validation for domain configurations

Optimization Proposal

1. Enhanced Subdomain Middleware

Create a new, more robust subdomain middleware system:

// app/Http/Middleware/DomainResolver.php
class DomainResolver
{
    public function handle($request, Closure $next)
    {
        $domain = $this->resolveDomain($request);
        
        // Set domain context
        app()->instance('domain.context', $domain);
        
        return $next($request);
    }
    
    private function resolveDomain($request): DomainContext
    {
        // Logic to determine domain type and set appropriate context
    }
}

2. Domain Configuration Service

// app/Services/DomainService.php
class DomainService
{
    public function getSubdomainType(string $subdomain): string
    {
        // Determine if subdomain is fixed (my, in, checkout) or dynamic (user shop)
    }
    
    public function isValidUserShop(string $slug): bool
    {
        // Validate user shop existence and status
    }
    
    public function getDomainConfiguration(): array
    {
        // Return centralized domain configuration
    }
}

3. Improved Route Organization

routes/
├── web.php                 # Route registration orchestrator
├── domains/
│   ├── main.php           # Main domain (mivita.care)  
│   ├── shop.php           # Alternative domain (mivita.shop)
│   └── subdomains/
│       ├── crm.php        # my.mivita.care
│       ├── portal.php     # in.mivita.care  
│       ├── checkout.php   # checkout.mivita.care
│       └── user-shops.php # {slug}.mivita.care
├── api/
│   └── v1.php            # API routes
└── shared/
    ├── legal.php         # Legal pages (shared across domains)
    └── common.php        # Common functionality

4. Domain Context System

// app/Domain/DomainContext.php
class DomainContext
{
    public function __construct(
        public readonly string $type,        // 'main', 'crm', 'portal', 'checkout', 'user-shop'
        public readonly string $domain,      // Full domain
        public readonly ?string $subdomain,  // Subdomain part
        public readonly ?UserShop $userShop  // For user shop contexts
    ) {}
    
    public function isMainDomain(): bool
    public function isCrmDomain(): bool  
    public function isPortalDomain(): bool
    public function isCheckoutDomain(): bool
    public function isUserShopDomain(): bool
}

Implementation Benefits

1. Performance Improvements

• Reduced Database Queries: Cache user shop validity
• Faster Route Resolution: Dedicated route files per domain type
• Optimized Middleware Stack: Domain-specific middleware application

2. Maintainability

• Clear Separation of Concerns: Each domain type has its own route file
• Centralized Configuration: Single source of truth for domain settings
• Consistent Architecture: Uniform handling across all domain types

3. Scalability

• Easy Subdomain Addition: New subdomains can be added without touching existing code
• Flexible Configuration: Environment-agnostic domain management
• Modular Structure: Independent development of domain-specific features

4. Security Enhancements

• Domain Validation: Proper validation of all subdomain requests
• Context Isolation: Clear boundaries between different application areas
• CSRF Protection: Domain-aware CSRF token handling

Migration Strategy

Phase 1: Foundation

1. Create new DomainService and DomainContext classes
2. Implement enhanced DomainResolver middleware
3. Add domain configuration management

Phase 2: Route Reorganization

1. Create new route structure under routes/domains/
2. Migrate existing routes to new organization
3. Update route service provider

Phase 3: Testing & Optimization

1. Comprehensive testing of all domain types
2. Performance optimization and caching
3. Documentation updates

Phase 4: Deployment

1. Gradual rollout with fallback mechanisms
2. Monitor performance and functionality
3. Remove old code after successful migration

Risk Assessment

Low Risk

• Domain service implementation
• Route reorganization
• Configuration centralization

Medium Risk

• Middleware replacement (affects all requests)
• Session handling changes
• Cache invalidation

High Risk

• User shop subdomain handling (affects customer shops)
• Payment domain changes (affects revenue)

Monitoring & Rollback Plan

Monitoring Points

• Response times per domain type
• Error rates by subdomain
• User shop accessibility
• Payment processing success rates

Rollback Strategy

• Feature flags for gradual enablement
• Database transaction rollbacks for configuration changes
• Immediate fallback to current middleware if critical issues arise

Conclusion

This optimization will provide a more maintainable, scalable, and performant multi-domain architecture while preserving all existing functionality. The modular approach allows for incremental implementation and testing, reducing deployment risks.