Atraxion Webshop Migration - Overview¶
Project Goal¶
Complete rewrite of the Atraxion e-commerce platform from a legacy PHP application to a modern Symfony 8 architecture. This is not a migration but a from-scratch rebuild where every feature is re-evaluated for improvements.
Current State¶
The existing application is a monolithic PHP application handling: - E-commerce (tyres, wheels, accessories) - Multi-tenant white-label webshops - Stock import from 50-60 suppliers - Export to platforms (Tyre24, Autodoc, etc.) - Vehicle data management and product-vehicle mappings - B2B EDI orders - ERP integration (Odoo) - Loyalty program (Arteel) - And much more...
Problem: The application does too much in one codebase, making it difficult to maintain, test, and scale.
New Architecture: Island Structure¶
The new architecture splits functionality into separate Symfony applications (islands) with well-defined scopes, communicating via a mixed contract model:
- Synchronous REST APIs for low-latency request/response reads.
- Asynchronous events for cross-island state propagation.
┌─────────────────────────────────────────────────────────────────┐
│ WEBSHOP │
│ (Multi-tenant, Admin, Notifications, ERP sync, Loyalty) │
│ ▲ │
│ │ API + EVENTS │
└───────────────────────────┼─────────────────────────────────────┘
│
┌───────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ STOCK IMPORT │ │ PLATFORM │ │ VEHICLE │
│ │ │ EXPORT │ │ DATA │
│ FTP ← CSV/XML│ │ FTP/API/EDI │ │ │
│ (isolated) │ │ │ │ │
│ │ │ Pricing: │ │ │
│ │ │ AK + margin │ │ │
│ │ │ + weight │ │ │
└──────────────┘ └──────────────┘ └──────────────┘
┌───────────────────────────────────────┐
│ ERP MIDDLEWARE │
│ (existing Symfony app) │
└───────────────────────────────────────┘
Islands Overview¶
1. Webshop (Core Application)¶
The main customer-facing and admin application.
Scope: - Multi-tenant with white-labeling (logo, custom domain, pricing) - E-commerce: product catalog, cart, checkout, orders - Customer management: B2B/B2C, authentication, registration flows - Admin interface: custom Twig, role-based access - Notifications: email templates (3-layer system) - ERP sync: via existing middleware API - Loyalty: Arteel integration (abstract, tenant-specific) - Coupons: discount system with multiple award types - EDI: B2B orders via XML
Key characteristics:
- Tenant-aware on database level (shared database with tenant_id)
- Products and vehicles are shared master data (managed by Super Admin)
- Tenants have visibility rules (which products/vehicles they can see)
- Custom domains: [tenantname].tyrecloud.be
2. Stock Import¶
Batch processing service for importing supplier stock.
Scope: - FTP server (isolated for security) - CSV/XML file processing from 50-60 suppliers - Article matching engine with confidence scoring - Manual review queue for uncertain matches - Audit trail
Key characteristics: - Isolated from webshop for security - Communicates via REST API - Supplier-specific configuration (file format, field mapping)
3. Platform Export¶
Export service for external sales platforms.
Scope: - Export to Tyre24, Autodoc, and other platforms - Pricing engine: AK + margin + weight-based transport - Output via FTP, API, or EDI per platform - Order import from platforms - Order status and tracking export
Key characteristics: - Complex pricing rules per platform - Margin configuration at multiple levels (category, brand, type, diameter, size, article)
4. Vehicle Data¶
Vehicle data management and product-vehicle mapping.
Scope: - Multi-source: DriveRight (current), WheelSize (future) - Adapter pattern for source abstraction - Manual vehicle creation (for new models not yet in sources) - Later linking to external sources for updates - Product-vehicle mapping logic (complex matching criteria)
Key characteristics: - Source-agnostic with adapters - Sync mechanism for updates - Complex matching logic for wheels/tyres to vehicles
5. ERP Middleware (Existing)¶
Existing Symfony application for Odoo integration.
Scope: - Bidirectional sync with Odoo ERP - Customer sync - Order sync - Product price sync - Invoice retrieval
Key characteristics:
- Already built in Symfony
- Will be integrated/called from Webshop
- Contract baseline: erp-middleware/00-erp-boundary-contract.md
Communication Between Islands¶
All islands communicate via sync + async contracts:
| Flow Type | From | To | Purpose |
|---|---|---|---|
| Sync REST | Webshop | Stock Import | Operational read endpoints for stock/import status |
| Sync REST | Webshop | Vehicle Data | Get vehicle specs and fitment projections |
| Sync REST | Webshop | ERP Middleware | Sync customers/orders and fetch invoice/payment state |
| Sync REST | Platform Export | Webshop | Read products/prices/availability for export feeds |
| Async Event | Stock Import | Webshop | Publish stock and supplier-price updates |
| Async Event | Platform Export | Webshop | Publish imported platform orders and status updates |
| Async Event | Vehicle Data | Webshop | Publish fitment/mapping refresh updates |
| Async Event | Webshop | ERP Middleware | Publish customer/order upsert requests |
| Async Event | ERP Middleware | Webshop | Publish ERP sync confirmations, invoices, and payment updates |
Cross-island writes use outbox/inbox with idempotency keys and replay support. See 02-island-boundaries-and-performance.md.
Shared Code Strategy¶
Internal Shared Package Policy (Capped)¶
Internal shared packages are capped at 3:
atraxion/contracts- Cross-island API/event contracts (DTOs and schemas only)atraxion/integration-sdk- Integration primitives (HTTP/FTP wrappers, retries, idempotency helpers)atraxion/foundation- Stable cross-island primitives (Money, IDs, clock abstractions)
Rules:
- No shared mutable domain bundles (
Article,Order,Vehicle, etc.). - Domain entities and business workflows stay island-local.
- New shared package requires the extraction criteria in
02-island-boundaries-and-performance.md.
External Integrations¶
External service adapters (Pay.nl, Transsmart, DriveRight, platform connectors) are implemented inside the owning island unless extraction criteria are explicitly met.
Distribution¶
- Shared packages are distributed via private Packagist or Git repositories.
- Island applications version and release independently.
Development Approach¶
- Parallel development: Build new Symfony apps while current system runs
- Big-bang switch: Switch over when new system is complete and tested
- From scratch: Every feature re-evaluated, not just migrated
- BDD testing: Gherkin/Behat for functional specs
- Clean architecture: Clear separation of concerns
Priority Order¶
- Products - Core catalog functionality
- Orders - Order processing and fulfillment
- Customers - Customer management and authentication
- Vehicles - Vehicle data and mappings
- Integrations - External service connections
- Loyalty - Points and rewards
- Content - CMS features (sliders, banners, pages)
Must-Have Integrations (Day 1)¶
- Pay.nl (payments)
- Transsmart (shipping)
- EDI (B2B orders)
- Tyre24 (platform)
- Autodoc (platform)
- DriveRight (vehicle data)
Nice-to-Have Integrations¶
- Arteel (loyalty)
Would-Have Integrations¶
- Matomo (analytics)
Documentation Structure¶
This documentation is organized in layers:
- Overview (this document) - Architecture, islands, communication
- Boundary & Performance Baseline - See
02-island-boundaries-and-performance.mdfor service/package guardrails and scale strategy - Architecture Review Checklist - See
03-architecture-review-checklist-template.mdfor ADR go/no-go gates - Architecture Conformance Passes - See
04-architecture-conformance-pass-2026-02-07.md(baseline) and05-architecture-conformance-pass-2026-02-07-followup.md(post-remediation follow-up) - ERP Boundary Contract - See
erp-middleware/00-erp-boundary-contract.mdfor Webshop <-> ERP sync/async contracts - Priority-H Delivery Batch - See
06-priority-h-delivery-batch-2026-02-07.mdfor decision and execution order on critical migration scope - Performance Implementation Backlog - See
08-performance-implementation-backlog-2026-02-08.mdfor schema/index specs, queue/worker model, SLI targets, and rollout gates - Delivery Backlog + BDD Starter - See
09-delivery-backlog-and-bdd-starter-2026-02-08.mdandbdd/for execution tasks and initial runnable acceptance suite - Per island - Detailed specs per application
- Per feature - Deep dives into complex features
Each document is written to be self-contained enough for an AI to implement the feature without extensive clarification.