Lendo Core Domain Laravel Package

Product Decisions This Supports

• Build vs. reuse (shared platform vs. per-service duplication): the package is positioned as a common domain layer for Lendo services, bundling an event engine and a read-model engine. The core PM decision it informs is whether event handling and projection logic should be built once centrally and consumed by every service, or re-implemented (and re-debugged) inside each product team's codebase. At zero dependents today, the decision is "should we be the first/second adopter," not "is the ecosystem already committed."
• Roadmap sequencing for event-driven features: anything that needs an append-only history, replay, projections, or derived read models — audit/compliance trails, activity timelines, reporting views, cross-service integration events, backfills for new features — gets materially cheaper if the engine already exists. This can justify pulling such items forward, or conversely de-risking them by capping scope in v1.
• Architecture standardization: whether CQRS/event sourcing becomes the default pattern for new services or stays an opt-in pattern for a subset. A shared engine makes "default" viable; without one, every team's bespoke event loop becomes an integration and onboarding tax.
• Buy vs. build against external infrastructure: the alternative to this package is typically a vendor/OSS event store (EventStoreDB, Kafka plus bespoke consumers) or a SaaS event platform. This is the in-house option in that comparison — relevant to licensing spend, operational burden, and data-residency constraints.
• Investment/ownership decisions: adopting a shared core means funding an owner — release cadence, semver discipline, docs, migration guides, on-call. That is a staffing and maintenance-budget decision, not just a technical one.
• Use cases it plausibly unlocks: domain event publishing between Lendo services, read models for dashboards/search/reporting that would otherwise hit transactional tables, replayable state for debugging and feature backfills, and a consistent event envelope/schema across teams.

When to Consider This Package

Consider it when:

• You have (or credibly expect) multiple PHP/Laravel services that need to emit or consume domain events, or maintain read models. One service alone rarely justifies a shared core — implement inline.
• You are already inside, or closely aligned with, the Lendo STP Gdańsk organization. With no public stars, no dependents, and no external community, this is almost certainly an internal package; adoption outside that boundary means forking and owning a fork.
• You need cross-service consistency more than you need novelty — a single event envelope, one projection runner, one place to fix a deserialization bug.
• The team accepts event-sourcing trade-offs: eventual consistency, idempotent handlers, replay safety, schema versioning. A shared engine lowers boilerplate but does not remove the conceptual cost.
• Due diligence passes: readable docs, meaningful test coverage, tagged releases/semver, an identified maintainer, and a stated upgrade path. Zero dependents means there is no field evidence of production hardening — verify directly with the owning team and inspect the code before committing.
• Your event volumes and latency targets fit a PHP/Laravel request-and-worker model.

Look elsewhere when:

• You need a vendor SLA, public-community support, or long-term OSS guarantees. This package offers none of those signals.
• You have a single service, or no near-term event-driven roadmap. The abstraction cost will exceed the savings.
• You require very high throughput, strict ordering guarantees at scale, or mature streaming operations — a dedicated event-streaming platform is the better fit.
• Your stack is not PHP/Laravel, or you are standardizing on a different domain-event contract.
• No clear owner exists. An unowned shared core becomes a frozen dependency that every service is afraid to upgrade — a worse outcome than duplication.

How to Pitch It (Stakeholders)

Executive summary: lendo-core-domain is an internal Laravel/PHP library that provides a shared event engine and read-model engine for Lendo services. The pitch is build once, use many: instead of each product team writing and maintaining its own event publishing and projection code, we standardize on one component. That compresses delivery time for any feature needing history, replay, or derived reporting views, reduces duplicated engineering and repeated bug-fixing, and gives us one consistent event contract across services. The trade-off is ownership: a shared dependency must be maintained, versioned, and supported, and today it shows no public adoption signals — so we should treat it as a promising internal asset requiring validation, not a proven platform.

For engineering: one implementation of event handling and read models instead of N; a single place to fix correctness and performance issues; consistent event schemas that make cross-service integration predictable. Ask for: docs, tests, release/versioning history, and the maintainer's upgrade policy before the first production dependency.

For finance/operations: avoids per-team rebuild cost and can displace third-party event-store licensing. The real cost line is maintenance and on-call for the shared core — budget it explicitly rather than assuming "free internal library."

Recommended posture: run a bounded pilot — one non-critical service or one reporting read model — to prove the engine under real load and validate the upgrade story. If the pilot holds, standardize new event-driven services on it and assign a named owner. If it stalls, the fallback is a thin internal wrapper, and the sunk cost stays small. This keeps the downside capped while preserving the strategic upside of a common domain layer.