Addressing Bundle Laravel Package

Technical Evaluation

Architecture fit. The package is a Symfony2 bundle — a Bundle class registering DI services, Doctrine ORM mappings, Symfony Form types, and Twig views. It is not a Laravel package: there is no service provider, no Eloquent integration, no publishable config, no facades, no Artisan commands. For a Laravel target, nothing of the runtime wiring is consumable. What is transferable is the domain design: Address, Country, Province, and Zone, the Country→Province hierarchy that is deliberately extensible to deeper geographic levels, and the zone-membership contract that matches any address against every defined zone. As a TPM, frame this as a reference architecture and schema donor, not a dependency.

Integration feasibility. Low for Laravel, and the correct answer is "do not install." The repository is explicitly [READ-ONLY] — the Sylius lifecycle signal that the code has been absorbed into Sylius core and this standalone artifact is frozen. Its Composer constraints will pin symfony/*, doctrine/orm, and PHP to older majors that fight a modern Laravel dependency graph, and Doctrine mappings cannot be consumed by Eloquent regardless. Integration cost is therefore "read the schema and business rules, reimplement natively," and the effort is measured in days, not weeks, because the model is small.

Technical risk. Dominated by abandonment, not code quality. The underlying Sylius domain modeling is sound and battle-tested inside Sylius; the artifact itself is unmaintained. Signals to cite in a risk register: 33 stars, zero dependents, maturity rated "readme," READ-ONLY status, no community answers to fall back on. Country/province reference data will be stale and no one is merging ISO 3166 or subdivision updates. Zone matching is simple relational membership testing, so porting risk is low; carrying the bundle as a dependency is the risk. MIT license means zero legal friction for adapting the model.

Key questions.

• Is the target actually Laravel, or Symfony/Sylius? If Sylius, use Sylius core addressing, not this repo.
• Do we need the Zone abstraction (grouping countries/provinces for tax and shipping), or only address storage? The zone layer is the expensive, valuable part.
• Who owns country/province reference data if we copy the schema — and what is the refresh cadence?
• What PHP/Laravel versions does the platform enforce, and is there an existing geography package already in the stack?
• Are market-specific address formats (province required in some countries, absent in others) in scope now or a later epic?
• Is a support/ownership commitment required, which would categorically rule this out?

Integration Approach

Stack fit. Poor as a dependency, strong as a conceptual donor. Adopt the patterns natively: countries, provinces, zones, zone_members, and addresses as the entity set; Country has many Provinces; Zone contains countries and/or provinces; Address belongs to Country and optionally Province; zone matching is a lookup against membership, decoupled from any tax or shipping rule engine. Also adopt the extensibility posture — custom address fields without a schema fork, and address models split by type (billing/shipping) where requirements demand it.

Migration path. Do not composer require this bundle. Instead: (1) translate the schema into Laravel migrations; (2) express it as Eloquent models with relationships mirroring the Doctrine mappings; (3) source ISO 3166 country and subdivision data from a maintained dataset rather than the bundle's fixtures; (4) implement zone matching as a small, tested domain service (address → matched zones); (5) build forms with Laravel validation and Blade/Livewire, using the bundle's form coverage as a scope baseline for common address actions. If the team is exiting Sylius, target Sylius core addressing directly — this repo is the deprecated extraction.

Compatibility. Treat as incompatible until proven otherwise. Expect constraints on symfony/framework-bundle, doctrine/orm, and PHP that conflict with Laravel's bundled Symfony components; a dual-ORM bridge is not a viable design. Verify constraints before any spike — the expected outcome is a hard stop, which is acceptable and should be recorded as the decision, not treated as a failed spike.

Sequencing.

1. Decision gate: confirm and document "not installing; reference only." Get this into the architecture decision record so it does not resurface.
2. Schema and migrations: countries, provinces, zones, zone_members, addresses. Include index and uniqueness intent on zone membership.
3. Reference data import: ISO country/province dataset with a defined refresh mechanism.
4. Domain service: zone matching, unit-tested independently of storage and HTTP.
5. Persistence and API/UI surface: Eloquent models, then forms for checkout and account address capture.
6. Rules layer: tax and shipping rate calculation on top of matched zones — explicitly a separate, larger epic.
7. Market-specific address validation: per-country required-field rules, sequenced by launch markets.

Operational Impact

Maintenance. Low and fully owned, provided we never adopt the bundle. Copied schema and a ~200-line zone-matching service are ours to evolve; there is no upstream to track, which is a feature here. The real ongoing cost is reference data: country and subdivision lists change and require a refresh path plus a review step. Assign that explicitly — it is the most likely orphaned task.

Support. No vendor, no community, no SLA, no security patching on the artifact. MIT means we may adapt freely and carry no obligation. For internal stakeholders, state plainly: this package cannot be supported, so it will not appear on the approved-dependency list. Support burden shifts to our own team and is small because we own the code.

Scaling. The model scales comfortably — geography tables are small and highly cacheable, zone membership is a bounded set, and address matching is a cheap lookup that belongs behind a cache. The scaling risk is not the data model but the rules layer built on top: naive per-request tax/shipping evaluation against zones will become a hot path. Plan for zones-plus-rules to be resolved and cached, not recomputed per address.

Failure modes.

• Stale reference data: addresses in newly created or renamed subdivisions fail to resolve; country lists drift. Mitigate with a scheduled import and a diff review.
• Stakeholder conflation of "zones" with "tax engine": the package models geography; it computes nothing. Expect scope confusion and correct it early in planning language.
• Accidental dependency adoption: a developer sees a Sylius repo referenced in an ADR and attempts to install it. Mitigate by recording the rejection and naming the internal module as the source of truth.
• Address format assumption: a single global form fails in markets where province is required or where the concept does not exist. Treat per-market validation as planned work, not a bug.
• Over-abstraction on simple needs: if requirements are truly one flat address table plus a country list, the zone/province model is over-engineering and will slow delivery. Gate adoption on the presence of multi-market or regional pricing requirements.

Ramp-up. Fast. A Laravel engineer reads the four entity relationships and the zone-membership idea in an hour and can implement the schema the same day. Allocate roughly one engineer-week for migrations, models, reference data import, zone matching with tests, and basic forms — and treat this estimate as the value delivered by the reference design, versus the longer design-from-scratch path. Ramp-up risk is minimal because there is no unfamiliar framework runtime to learn; the only genuine learning is market-specific address semantics, which no package solves.