Technical Evaluation

Architecture Fit

Symfony Bundle in Laravel: The package is a Symfony bundle, requiring significant adaptation for Laravel. Native Laravel integration would demand middleware, service providers, or a microservice approach to bridge Symfony’s HttpKernel and Laravel’s Illuminate\Container. The bundle’s reliance on baks-dev/core (Symfony-centric) introduces architectural friction unless the core library is fully adopted.
Domain-Specificity: Tailored exclusively for Avito’s FBS/DBS workflows, limiting reuse for other marketplaces. Ideal for Avito-centric projects but not a generic e-commerce solution.
Modularity: Commands (baks:users-profile-type, baks:delivery) suggest extensibility, but Laravel’s Artisan CLI and service container would need custom wrappers to avoid Symfony dependencies.

Integration Feasibility

PHP 8.4+ Constraint: Requires Laravel 11+ (PHP 8.3+) or 12+ (PHP 8.4+), necessitating potential upgrades and testing.
Symfony Core Dependency: Hard dependency on baks-dev/core:^7.4 risks vendor lock-in. If this core library is abandoned, the entire integration becomes unsustainable.
Database Schema: Likely introduces Avito-specific tables (e.g., avito_orders, delivery_methods). Migration conflicts with Laravel’s Eloquent or Doctrine (if used) are probable without abstraction layers.
Event-Driven Workflows: Avito’s order lifecycle (e.g., payment webhooks) may conflict with Laravel’s native queues/jobs unless decoupled via events (e.g., Laravel’s Events facade) or message brokers (e.g., RabbitMQ).

Technical Risk

Undocumented Assumptions: Minimal English documentation (README in Russian) risks misalignment with Laravel’s conventions (e.g., service binding, Facade usage).
Testing Gaps: No visible CI/CD or Laravel-specific tests. Risk of hidden dependencies (e.g., Symfony’s EventDispatcher) breaking Laravel’s event system.
Future-Proofing: Last release in 2026 (future date) suggests either:
- A placeholder for a hypothetical package, or
- A cutting-edge but unproven library. Validate with the maintainer for roadmap clarity.
License Compatibility: MIT license is permissive, but ensure no conflicts with proprietary Avito API usage or Laravel’s proprietary extensions.

Key Questions

Strategic Alignment:
- Is Avito a core or niche use case? If niche, evaluate if a lighter wrapper (e.g., Guzzle + custom models) suffices.
Symfony vs. Laravel Tradeoffs:
- Can baks-dev/core be replaced with Laravel’s built-in features (e.g., spatie/laravel-activitylog for profiles, laravel-queue for jobs)?
Data Isolation:
- Will Avito’s schema require shared databases or a microservice approach to avoid Laravel schema conflicts?
Maintenance Ownership:
- Who will support baks-dev/core updates? Will Laravel’s deprecations (e.g., Facade changes in v11+) break the bundle?
Alternatives:
- Are there Laravel-native Avito SDKs (e.g., avito/marketplace-api) or generic packages (e.g., webkul/laravel-marketplace) that fit better?
Performance Overhead:
- How will Symfony’s event system and HttpKernel impact Laravel’s request lifecycle? Benchmark with blackfire.io.

Integration Approach

Stack Fit

Laravel Compatibility Options:
- Option 1: Symfony Bridge (High Effort)
  - Use spatie/laravel-symfony to embed the bundle.
  - Pros: Leverage existing Symfony logic.
  - Cons: Complex setup; introduces Symfony bloat (e.g., HttpKernel, EventDispatcher).
- Option 2: Custom Wrapper (Medium Effort)
  - Extract core Avito logic (e.g., order creation, webhooks) into Laravel services.
  - Pros: Decoupled from Symfony; easier maintenance.
  - Cons: Reimplement bundle features (e.g., profile types, CLI commands).
- Option 3: Microservice (Low Effort for Isolation)
  - Deploy the bundle as a separate Symfony service (e.g., Lumen) and call it via HTTP/queues.
  - Pros: Clean separation; scalable.
  - Cons: Network latency; operational overhead for inter-service communication.
PHP Version:
- Upgrade Laravel to 12.x (PHP 8.4+) to match the package’s requirements. Test thoroughly for breaking changes (e.g., Facade deprecations).

Migration Path

Assessment Phase:
- Audit baks-dev/core dependencies for Laravel conflicts (e.g., symfony/console vs. Laravel’s Artisan).
- Map Avito’s order lifecycle to Laravel’s existing workflows (e.g., Illuminate\Queue for delivery jobs, Illuminate\Events for webhooks).
Proof of Concept:
- Test the bundle in a Lumen project first (closer to Symfony).
- Validate database migrations against Laravel’s schema builder (e.g., use Doctrine\DBAL for raw SQL).
Incremental Rollout:
- Start with FBS/DBS delivery models as separate features, using Laravel’s middleware/policies for access control.
- Gradually replace custom Laravel logic with bundle components (e.g., payment processing).

Compatibility

Database:
- Use Laravel’s Doctrine DBAL or raw migrations to handle baks-dev/core schemas.
- Example: Extend Illuminate\Database\Migrations\Migration to include Avito tables:
```
Schema::connection('avito')->create('avito_orders', function (Blueprint $table) { ... });
```
Artisan Commands:
- Register Symfony commands in Laravel’s App\Console\Kernel:
```
protected $commands = [
    \BaksDev\AvitoOrders\Command\AvitoFbsCommand::class,
    // Override command handling to use Laravel’s IoC
];
```
- Mitigation: Create Laravel-specific commands that delegate to Symfony commands internally.

Service Providers:

Bind Symfony services to Laravel’s container using bind() or extend():

$this->app->bind(
    \BaksDev\Core\Avito\Service::class,
    fn($app) => new \BaksDev\Core\Avito\Service(
        $app->make('db.connection.avito')
    )
);

Event System:

Bridge Symfony events to Laravel’s Events facade:

// In a service provider
$symfonyDispatcher = new \Symfony\Component\EventDispatcher\EventDispatcher();
Event::listen('avito.order.created', function ($event) use ($symfonyDispatcher) {
    $symfonyDispatcher->dispatch(new \BaksDev\Core\Event\OrderCreatedEvent($event->order));
});

Sequencing

Phase 1: Dependency Setup
- Add baks-dev/core and baks-dev/avito-orders to composer.json.
- Configure PHP 8.4+ runtime and Laravel 12+.
- Set up a separate database connection for Avito (config/database.php):
```
'connections' => [
    'avito' => [
        'driver' => 'mysql',
        'url' => env('DATABASE_AVITO_URL'),
        'database' => env('DATABASE_AVITO_DATABASE'),
        // ...
    ],
],
```
Phase 2: Schema Integration
- Run Avito migrations alongside Laravel’s using a custom artisan command:
```
php artisan migrate --path=/vendor/baks-dev/core/src/Resources/migrations
```
- Seed initial profile_types and delivery_methods via Laravel’s seeder.
Phase 3: Feature Adoption
- Implement FBS/DBS flows using Laravel’s middleware/policies:
```
// Example: Policy for Avito orders
class AvitoOrderPolicy
{
    public function update(FbsUser $user, AvitoOrder $order) {
        return $user->isAvitoFbsAgent();
    }
}
```
- Replace custom payment logic with the bundle’s baks:payment:avito-fbs command, wrapping it in a Laravel job.

Phase 4: Testing

Run phpunit --group=avito-orders in a Laravel-compatible environment.

Add Laravel-specific tests for edge cases (e.g., queue failures, webhook retries):

public function test_avito_order_creation_fires_laravel_event()
{
    Event::fake();
    $this->artisan('baks:orders:create-avito', ['--fbs' => true]);
    Event::assertDispatched(\App\Events

Avito Orders Laravel Package