Multi Domain Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Multi-Tenant by Domain: The bundle aligns well with domain-based multi-tenancy (e.g., app1.example.com, app2.example.com), where each tenant is isolated by DNS/subdomain. This is a niche but valid use case for Symfony applications requiring per-domain data segregation.
• Entity-Level Isolation: The DomainTrait enforces domain-specific visibility at the ORM entity level, which is a clean but rigid approach. It assumes all entities requiring domain isolation must inherit the trait, limiting flexibility for mixed-domain entities.
• No Tenant Context Switching: Unlike tenant-aware bundles (e.g., Laravel Tenancy), this does not support dynamic tenant context switching (e.g., via middleware or request attributes). It’s static—entities are either visible or hidden based on the current domain.
• Symfony 2.x Legacy: The bundle is Symfony 2.x-specific (e.g., symfony/class-loader:2.* in require-dev), which may introduce compatibility risks with modern Symfony (5.x/6.x) or Laravel ecosystems.

Integration Feasibility

• Laravel Compatibility: Low. The bundle is Symfony-specific (e.g., Doctrine ORM, Symfony EventDispatcher, bundles.php). Porting to Laravel would require:
  • Replacing Symfony’s DomainTrait with Laravel’s model observers or query scopes.
  • Rewriting domain resolution logic (Symfony’s RequestStack → Laravel’s Request facade).
  • Handling Symfony’s event system (e.g., KernelEvents) via Laravel’s service providers or middleware.
• Database Schema Impact: Minimal. The bundle does not modify schemas—it relies on a domain column (assumed to be added manually) and filters queries via Doctrine’s DQL or QueryBuilder.
• Routing/URL Generation: Not addressed. The bundle does not handle:
  • Domain-aware route generation (e.g., route('page', ['domain' => 'app1'])).
  • Redirects between domains (e.g., app1.example.com → app2.example.com).
  • Asset/URL rewriting (e.g., CSS/JS paths with domain-specific hashes).

Technical Risk

Key Questions

1. Why Symfony 2.x? Is this a legacy system, or is there a need to avoid modern Symfony/Laravel?
2. Domain Resolution Logic: How are domains mapped to tenants? (e.g., subdomains, wildcards, or a database table?)
3. Mixed-Domain Entities: Are some entities shared across domains, or is strict isolation required?
4. Performance Impact: Will domain filtering add significant overhead to queries?
5. Fallback Domain: How is the "default" domain handled (e.g., example.com vs. app1.example.com)?
6. Testing Strategy: How will domain-specific behavior be tested (e.g., mocking RequestStack)?

Integration Approach

Stack Fit

• Symfony 2.x: Native fit—minimal changes required beyond installation and trait usage.
• Symfony 3.x/4.x/5.x/6.x: Partial fit—may require:
  • Composer dependency overrides (e.g., symfony/class-loader:^4.0).
  • Event listener adjustments (e.g., kernel.request vs. kernel.controller).
• Laravel: Poor fit—requires rewrite of:
  • Domain resolution (Symfony’s RequestStack → Laravel’s Request).
  • Doctrine integration (Laravel uses Eloquent; may need a query scope or model observer).
  • Event system (Symfony events → Laravel’s service providers or events).

Migration Path

Option 1: Symfony 2.x (Minimal Effort)

1. Installation:

   composer require appventus/multi-domain-bundle:dev-master
   

2. Register Bundle:

   // app/AppKernel.php
   $bundles[] = new AppVentus\MultiDomainBundle\AvMultiDomainBundle();
   

3. Apply Trait to Entities:

   use AppVentus\MultiDomainBundle\Traits\DomainTrait;
   
   class Page
   {
       use DomainTrait;
       // ...
   }
   

4. Add Domain Column:

   /**
    * @ORM\Column(type="string", length=255)
    */
   private $domain;
   

5. Configure Domain Resolution:
   • Override AvMultiDomainBundle's domain resolver (if needed) via a service override or event listener.

Option 2: Symfony 3.x+ (Moderate Effort)

1. Update Dependencies:

   "require": {
       "symfony/class-loader": "^4.0",
       "doctrine/orm": "^2.5"
   }
   

2. Replace Symfony 2.x-Specific Code:
   • Update RequestStack usage to RequestContext (if applicable).
   • Replace KernelEvents with modern Symfony event dispatching.
3. Test Domain Filtering:
   • Verify DQL/QueryBuilder filters work with new Doctrine versions.

Option 3: Laravel (High Effort)

1. Rewrite Core Logic:
   • Replace DomainTrait with a Eloquent trait:

     trait DomainAware
     {
         public static function bootDomainAware()
         {
             static::addGlobalScope('domain', function (Builder $builder) {
                 $domain = request()->getHost();
                 $builder->where('domain', $domain);
             });
         }
     }
     

   • Create a middleware to set the domain context:

     public function handle($request, Closure $next)
     {
         request()->setDomain(request()->getHost());
         return $next($request);
     }
     

2. Handle URL Generation:
   • Extend Laravel’s UrlGenerator to include domain-aware routes.
3. Test Edge Cases:
   • Subdomains, wildcards, and API requests.

Compatibility

• Doctrine ORM: High compatibility (if using Symfony’s ORM).
• Eloquent (Laravel): Low compatibility—requires custom query scopes.
• Custom Domain Logic: Flexible—can be extended via:
  • Symfony: Event listeners (kernel.request, kernel.controller).
  • Laravel: Middleware, model observers, or query scopes.
• Caching: Not addressed—domain filtering may bypass cache layers (e.g., Symfony’s HttpCache, Laravel’s Cache middleware).

Sequencing

1. Assess Tenancy Requirements:
   • Is domain isolation strict (no shared data) or partial (some shared entities)?
2. Choose Stack:
   • Symfony 2.x: Proceed with bundle as-is.
   • Symfony 3.x+: Update dependencies and test.
   • Laravel: Rewrite logic (highest effort).
3. Implement Domain Resolution:
   • Decide how domains map to tenants (e.g., database table, subdomain parsing).
4. Apply to Entities:
   • Start with critical entities (e.g., Page, User) before rolling out broadly.
5. Test Domain Transitions:
   • Verify behavior when switching between domains (e.g., app1.example.com → app2.example.com).
6. Handle Edge Cases:
   • Default domain, API requests, and CLI commands.

Operational Impact

Maintenance

• Symfony 2.x: Low maintenance—bundle is simple but tied to legacy Symfony.
• Symfony 3.x+: Moderate maintenance—may require updates for Doctrine/Symfony version changes.
• Laravel: High maintenance—custom implementation requires ongoing upkeep.
• Dependency Risk:
  • The bundle is abandoned (archived repo, no stars/dependents).
  • No security patches or bug fixes expected.

Support

• Documentation: Nonexistent—assume zero real-world usage.
• Community: None—no GitHub issues, discussions, or forks.