Sales Bundle Laravel Package

Product Decisions This Supports

• Order-domain design decisions, not a dependency decision. This bundle is a readable extract of a mature orders engine: order/order-item/order-item-unit aggregates, adjustments as the single pricing ledger, and an explicit order state machine. The value for a Laravel/PHP product is as a reference when deciding how to model orders — cart-to-order conversion, partial refunds/shipping, promotion and tax attribution, and lifecycle states. It is not a candidate for composer require.
• Build vs. buy, resolved toward "buy a maintained platform or build in-house." Archived, read-only, 18 stars, zero dependents. The decision it drives is not "adopt this" but "the standalone orders-engine market for PHP is thin — either adopt a maintained commerce platform or fund a focused in-house order aggregate." Use it to price and scope that build.
• Roadmap and tech-debt signal. The archive status indicates upstream consolidated order logic into Sylius core. If it appears in a dependency inventory, that is concrete evidence of an end-of-life Symfony 2.x stack and a migration line item belongs on the roadmap.
• Legacy audit input. If found in an existing app, quantify it: no security patching, no modern PHP/Symfony compatibility, no upstream to escalate to.
• Concrete patterns worth porting to Laravel. Adjustments (typed, signed, attributed rows for tax/shipping/promotions) instead of a mutable total column; derived totals recomputed on every state transition; order-item units (one row per quantity) so partial refunds, partial shipments, and partial discounts don't require invented refunded_quantity columns. These map cleanly onto Eloquent tables and are the deliverable from reading the source.
• Does not support any Laravel runtime decision. No service provider, no Eloquent integration, no Laravel event bridge — it assumes Symfony DI, Doctrine mappings, and Sylius conventions.

When to Consider This Package

Adoption criteria (deliberately narrow):

• You maintain an existing Symfony 2.x application that already depends on this bundle, and the cost of removal today exceeds one more release cycle. Treat it as a scheduled exit, not a choice.
• You want a compact, readable example of an orders domain model to inform a design doc or spike — read the source, do not add it to composer.json.

When to look elsewhere (i.e., almost always):

• Laravel: build the order aggregate on Eloquent with an explicit state machine (symfony/workflow works standalone, or a lightweight Laravel states package). This bundle is not a candidate.
• Modern Symfony: use the current supported Sylius order/promotion bundles. Do not pin a 2.x-era extracted bundle.
• You only need the state machine: use Symfony Workflow directly; most of the value is the state graph, not the persistence.
• Headless/API-first commerce: a managed or modern OSS commerce backend plus your own order read model will out-deliver this by a wide margin.
• Compliance-sensitive contexts (payments, tax, invoicing): archived code with zero dependents means zero eyes on it. Disqualifying.

Hard disqualifiers regardless of context: archived and read-only status, no maintainers, no dependents, and a Symfony 2.x baseline that will not resolve against a modern PHP runtime.

How to Pitch It (Stakeholders)

To executives: This is an archived, read-only component of a legacy PHP e-commerce framework, last relevant in the Symfony 2 era. It costs nothing and it is worth nothing as a dependency — adopting it means owning unmaintained code with no security patches and no one to call when it breaks. The real decision it surfaces is small and unavoidable: if we need order management, we either pay for a maintained platform or fund a focused in-house build. Recommendation: do not adopt; record it as a reference artifact, and if it already appears in our stack, add a migration line item to the roadmap.

To engineering: Treat sylius/sales-bundle as documentation. Its durable contribution is the domain shape — order and order-item aggregates, per-quantity order item units for partial refunds and shipments, adjustments as the uniform mechanism for discounts and fees, derived totals recomputed on every transition, and an explicit order state machine. That is worth a day of reading during design. It is not worth a Composer entry: it targets Symfony 2.x, is archived and read-only, has no dependents, and will not resolve cleanly against current PHP or Symfony. On Laravel, none of the runtime applies — build the aggregate with Eloquent plus a workflow component.

Proposed next step: a short spike (1–2 weeks) comparing (a) adopting a maintained commerce platform against (b) an in-house Laravel order domain modeled on the patterns above, with the archived bundle cited only as prior art.