Drom Products Laravel Package

Technical Evaluation

Architecture Fit

• Domain Alignment: The package is highly specialized for Drom.ru’s C2C marketplace model, offering pre-built logic for product variants, SKUs, inventory (including batch/serial tracking), and seller-specific compliance (e.g., ratings, return policies). This is a strong fit for:
  • Russian-language e-commerce platforms.
  • Marketplaces with seller-driven product listings (vs. brand-controlled catalogs).
  • Projects requiring Drom.ru API integrations (e.g., payment gateways, tax calculations).
• Symfony Bundle in Laravel: The package is a Symfony Bundle, which introduces architectural misalignment with Laravel’s ecosystem. Key conflicts:
  • Dependency Injection: Symfony’s Container vs. Laravel’s Illuminate\Container.
  • Routing: Symfony’s HttpKernel vs. Laravel’s Router.
  • ORM: Doctrine entities vs. Eloquent models.
  • Events: Symfony’s EventDispatcher vs. Laravel’s Events facade.
  • Validation: Symfony’s Validator vs. Laravel’s Validator (though similar, integration requires adapters).
• Modularity: The package appears to encapsulate product domain logic cleanly, making it swappable if wrapped properly. However, its tight coupling with baks-dev/core (a private/undocumented dependency) is a major risk.

Integration Feasibility

• Core Features (Inferred):
  • Product Entities: Models for products, variants, SKUs, and bundles.
  • Inventory Management: Batch/serial number tracking, stock levels.
  • Seller Compliance: Fields for seller ratings, return policies, and Drom-specific metadata.
  • Validation: Business rules for pricing, availability, and compliance.
  • API Endpoints: Likely RESTful routes for CRUD operations (if Symfony-based).
• Dependency Risks:
  • baks-dev/core (≥7.4): This is a critical unknown. Without access to its source or public API, integration is high-risk. Possible scenarios:
    • The core provides shared utilities (e.g., logging, caching) that can be replaced with Laravel equivalents.
    • The core contains domain logic (e.g., pricing rules) that may require rewriting.
  • Doctrine ORM: If your Laravel app uses Eloquent, you’ll need to:
    • Map Doctrine entities to Eloquent models.
    • Handle migrations (shared via doctrine/dbal or custom scripts).
    • Replace Doctrine-specific features (e.g., LifecycleCallbacks) with Laravel equivalents.
• Testing:
  • The package includes PHPUnit tests (--group=drom-products), but they are not publicly visible. Assess:
    • Test coverage for edge cases (e.g., concurrent inventory updates).
    • Integration with baks-dev/core (if tests pass without it, the package may be incomplete).

Technical Risk

Key Questions

1. What is the exact scope of baks-dev/core?
   • Does it provide shared utilities (replaceable) or domain logic (must be rewritten)?
2. Are there Laravel-specific alternatives?
   • Evaluate packages like spatie/laravel-product, orchid/software, or webpatser/laravel-uuid for core features.
3. How does the package handle multi-tenancy?
   • Critical for marketplaces; check if it supports tenant-aware product catalogs.
4. What’s the migration path for Doctrine schemas?
   • Can migrations be shared via doctrine/dbal, or must they be rewritten?
5. Are there public APIs for product variants/SKUs?
   • If the bundle only provides backend logic, you’ll need to build API endpoints separately.
6. How does it handle concurrency (e.g., inventory updates)?
   • Test for race conditions in high-traffic scenarios.
7. Is the bundle’s validation extensible?
   • Can you add custom rules without forking?
8. What’s the license compliance for forking?
   • MIT allows modifications, but ensure no baks-dev/core sub-licenses restrict use.

Integration Approach

Stack Fit

• Laravel Compatibility: Low to Medium
  • Symfony Bundle: Not natively compatible; requires adapters or rewrites.
  • PHP 8.4+: Aligns with Laravel 10+.
  • Doctrine vs. Eloquent: Conflict requires hybrid approach (shared DB schema + Eloquent models).
• Recommended Stack:

  Layer	Technology	Notes
  Backend	Laravel 10+ (PHP 8.4)	Use Laravel’s service container to replace Symfony DI.
  ORM	Eloquent (with Doctrine DBAL fallback)	Map Doctrine entities to Eloquent; use raw queries for complex logic.
  Routing	Laravel’s Route	Replace Symfony routes with Laravel controllers.
  Validation	Laravel’s Validator	Adapt Symfony validators to Laravel’s rules.
  Events	Laravel’s Events facade	Wrap Symfony’s EventDispatcher in a Laravel listener.
  Testing	Pest or PHPUnit	Replace Symfony test helpers with Laravel’s testing tools.
  API	Laravel Sanctum/Passport	If the bundle includes APIs, rewrite endpoints with Laravel’s auth.

Migration Path

1. Phase 0: Assessment (1 week)

   • Fork the repo and run tests locally.
   • Document all dependencies (especially baks-dev/core).
   • Identify critical features (e.g., product variants, inventory) vs. nice-to-haves.

2. Phase 1: Dependency Isolation (2 weeks)

   • Stub baks-dev/core: Replace its calls with mocks or minimal implementations.
   • Example:

     // Mock baks-dev/core service
     $this->app->singleton('baks.core.service', function () {
         return new class {
             public function calculateTax() { return 0; } // Stub
         };
     });
     

   • Replace Symfony services: Create Laravel service providers to wrap Symfony components.

     // app/Providers/SymfonyAdapterServiceProvider.php
     public function register()
     {
         $this->app->singleton(SymfonyEventDispatcher::class, function () {
             return new LaravelEventDispatcher(); // Custom adapter
         });
     }
     

3. Phase 2: Entity Mapping (2 weeks)

   • Convert Doctrine entities to Eloquent models.
   • Example:

     // app/Models/Product.php
     class Product extends Model
     {
         protected $fillable = ['sku', 'name', 'price', 'seller_id'];
     
         // Override bundle logic
         public function variants()
         {
             return $this->hasMany(ProductVariant::class);
         }
     }
     

   • Shared Migrations: Use doctrine/dbal for schema migrations if needed.

     composer require doctrine/dbal
     

4. Phase 3: API/Route Integration (1 week)

   • Replace Symfony routes with Laravel controllers.