Lendo Core Domain Laravel Package

Technical Evaluation

Architecture fit. The package advertises two high-leverage capabilities — an event engine and a read model engine — which together map to event sourcing plus CQRS-style projection. That is a strategic architecture decision, not a utility dependency. Before adoption, confirm whether the "event engine" is a full event store (append-only log, stream versioning, snapshots) or a thin event dispatcher over Laravel's queue/event system. The distinction changes the cost of adoption by an order of magnitude. If it is a genuine event store with projections, this package becomes the backbone of transactionality and reporting for every service that consumes it, and it should be evaluated with the same rigor as choosing a database.

Integration feasibility. Low external surface area implied by the repository (a Laravel-flavored common domain library). Integration is likely straightforward mechanically — composer install, service provider registration, configuration publishing — but the semantic integration is where effort lives: defining aggregates, event schemas, projection handlers, and the read-model persistence strategy. Expect to write adapters for persistence, tenancy, and observability. The absence of a published integration guide, versioned changelog, or example application is a meaningful gap.

Technical risk. The headline metrics — zero stars, zero score, zero dependents — are not a quality verdict but they are a signal provenance problem. A package with no visible dependents cannot be benchmarked against a community of consumers, which means: no proven upgrade path, no third-party bug reports, no ecosystem of examples. The principal risks are (1) bus factor: a "common domain" owned by a single internal team is a single point of organizational failure; (2) schema lock-in: event payloads are forever, and a premature event model is the most expensive kind of technical debt to reverse; (3) opaque maturity: without tests, CI badges, or release tags visible, we cannot assert production readiness; (4) namespace coupling: a lendo-stp-gdansk vendor namespace signals internal-only intent, raising questions about support guarantees and licensing for our use.

Key questions.

• Is this package intended for consumption outside the Lendo organization, and under what license and support model?
• What is the event store backend, and is replay/determinism guaranteed?
• Are event schemas versioned with an explicit upcasting strategy?
• What is the test coverage, and is there a CI pipeline we can inspect?
• Who is the owning team, and what is their on-call and deprecation policy?
• Does the read model engine support rebuilding projections from scratch without downtime?
• Is there an existing production consumer we can reference?

Integration Approach

Stack fit. Presumed Laravel/PHP with Composer — compatible with a standard Laravel service. The real fit question is which services should use it. A common domain package should be adopted by services that share the bounded context; forcing it onto adjacent services that merely want event dispatch is an anti-pattern and will produce coupling without benefit. Recommend a bounded-context mapping exercise before any code is written.

Migration path. Two viable paths, and they should be chosen deliberately rather than defaulted into:

1. Greenfield service — adopt the package in a new service where no legacy state exists; lowest risk, cleanest event model, but delivers value slowly.
2. Strangler on an existing service — introduce the event engine alongside the existing write path, dual-write initially, and build read models that shadow current queries. Higher risk, faster proof of value.

Avoid a big-bang migration of an existing transactional service. Event sourcing migrations fail when teams attempt to retrofit an event model onto a schema that was designed relationally; the event stream becomes a lossy mirror of the old tables.

Compatibility. Three compatibility axes to verify before committing: PHP version and Laravel framework version constraints (common domain packages frequently lag major Laravel releases); database driver support for the event store and read models; and queue/transport compatibility if projections run asynchronously. Pin the version explicitly and treat upgrades as deliberate events, not composer update side effects. If the package does not follow semantic versioning, budget for reading diffs on every bump.

Sequencing. Recommended order:

1. Spike (1–2 weeks): build a throwaway vertical slice — one aggregate, one event, one projection, one query — to validate the developer experience and surface undocumented assumptions.
2. Decision gate: compare the spike against a build-it-yourself estimate using a well-known library (e.g., a community event-sourcing package) or a plain outbox pattern. The build-vs-buy comparison must include the cost of not owning the core of your architecture.
3. Pilot service: one non-critical, read-heavy bounded context in production, with full observability instrumented from day one.
4. Read-model rollout: prove projection rebuild and replay in staging before any consumer depends on a read model.
5. Broaden: only after the pilot has survived a schema change and a replay.

Operational Impact

Maintenance. This is the critical risk. A shared domain package concentrates change: every event schema revision ripples to every consumer, and every consumer's needs push back on the owning team. Budget for a named internal owner (not just a dependency), a contribution process, and a versioning discipline. If the owning team is external to us, the maintenance calculus shifts from "engineering cost" to "vendor risk" and should be reflected in an SLA conversation, not a backlog ticket.

Support. Zero dependents and an internal namespace together imply no public support channel and no community knowledge base. Our team will be the first to encounter most failure modes. That means our ramp-up cost is effectively we are the documentation. Escalation paths and a direct line to the owning team must be established before the pilot, not after the first incident.

Scaling. Event-sourced systems scale well on writes but shift cost to the read side: projections, rebuilds, and catch-up lag become the operational surface. Key scaling questions are event store growth and archival policy, projection throughput under backlog, and whether read models can be rebuilt within an acceptable recovery window. If projections are synchronous, write latency and read-model availability become coupled — a design decision that is hard to reverse later.

Failure modes. The ones to design for explicitly:

• Projection lag or stall — reads go stale silently; needs lag metrics and alerting, not just error logs.
• Poison events — a single malformed event halts a projection; requires dead-letter handling and replay tooling.
• Schema drift — an event written by an older producer cannot be deserialized by a newer consumer; requires contractual schema versioning and upcasters.
• Replay storms — rebuilding a large projection can saturate the database; needs throttling and off-peak scheduling.
• Dual-write inconsistency during strangler migration — the classic failure of the transitional period.
• Upstream breakage — a minor-version package bump silently changing event serialization behavior.

Ramp-up. Event sourcing and CQRS impose a real cognitive tax on engineers accustomed to CRUD and ORM. Expect 4–8 weeks before a competent Laravel developer is productive and considerably longer before they are making good event-modeling decisions unsupervised. Plan for deliberate enablement — internal documentation, a reference service, and at least one experienced practitioner per team. The package's undocumented nature compounds this: onboarding material we write becomes an asset we own and must keep current.

Recommendation. Proceed to a time-boxed spike, not to adoption. The architectural direction is defensible, but the evidence base — no visible consumers, no public documentation, no maturity signals — is insufficient for a production commitment on a component that would sit at the center of the system. Gate adoption on the spike plus a documented answer to the ownership, versioning, and licensing questions.