Sdk Laravel Package

Product Decisions This Supports

• Build vs. buy for tactical DDD primitives. Every team adopting DDD writes the same first two weeks of code: Entity, AggregateRoot, ValueObject, DomainEvent, identity types, and a collection/assertion layer. This package is a candidate to buy (MIT, free) instead of build, which converts a recurring 1–2 week tax per new bounded context into a review decision.
• Whether to standardize DDD vocabulary across teams. If we adopt it, we get a shared, opinionated vocabulary for reviews and onboarding: "is this an aggregate or an entity?" becomes a concrete inheritance/interface question rather than a philosophical one. This is the strongest argument for adoption, and it's a consistency argument, not a capability argument.
• Roadmap scoping for a new bounded context. Choosing it sets the floor for what we build ourselves: the glue is handled, so the estimate should exclude primitive scaffolding and include only the actual domain logic, persistence mapping, and messaging.
• Architecture guardrails. It informs whether we allow framework types inside the domain layer. If we adopt base classes, we accept a light coupling to this library in the domain; if we reject it, we commit to hand-rolled primitives and the review discipline that requires.
• Vendor/risk budget allocation. With 1 star, 0 dependents, and a single maintainer, adoption implies a fork-and-own contingency. That is a resourcing decision, not a code decision, and it belongs in the same conversation.
• Not a decision it supports: event sourcing, CQRS transport, or message dispatching. Those need Symfony Messenger, Laravel's queue/bus, or a dedicated ES library — don't let "DDD SDK" imply it covers them.

When to Consider This Package

Adopt (or spike) when most of these hold:

• The team is new to DDD and would otherwise re-derive tactical patterns inconsistently across contexts.
• You are greenfield in at least one bounded context, so nothing has to be retrofitted.
• You need only tactical patterns — entities, aggregates, value objects, domain events — not full event sourcing or a CQRS framework.
• You are comfortable forking under MIT and treating upstream as a starting point rather than a supported dependency. Budget a half-day to read the source; it is small enough to audit fully.
• The primitives will be confined to the domain-model layer, with application/infrastructure code staying on framework-native tooling.

Look elsewhere or build in-house when:

• You have 0 dependents and 1 star as your only durability signal and cannot accept a single-maintainer dependency in a long-lived, regulated, or SLA-bound codebase. Here, copy the patterns, not the package.
• Your team is already fluent in DDD — the base classes will read as ceremony and you will fight the opinions rather than benefit from them.
• You need event sourcing, sagas, projections, or outbox, which is a different and much heavier category of tool.
• You need a guaranteed upgrade path or security responsiveness; no adoption means no ecosystem pressure on the maintainer.
• Your architecture forbids base-class inheritance in the domain (composition-over-inheritance shops). Check the API surface first — if the value is inheritance-based, this is a hard mismatch.
• You're on a Laravel-only stack that already gets what it needs from Eloquent, spatie/laravel-data, and the framework bus. Overlap may not justify a new dependency.

Recommended path: a timeboxed one-context spike (1–2 sprints) with a written go/no-go on API fit and fork cost, rather than a repo-wide standard. Do not let it into a second context until the first ships.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed accelerator for teams learning Domain-Driven Design. It replaces boilerplate our engineers would otherwise write and rewrite for each new module — realistically one to two weeks of effort per module — with a small, auditable library. The honest caveat is maturity: it has essentially no adoption yet, so we treat it as source we adopt, not a vendor we depend on. Mitigation is cheap (we can fork it, and it's ~a day to read), so the downside is bounded and the upside is faster, more consistent delivery on new modules. Recommendation: fund a small, timeboxed pilot in one greenfield module with a documented go/no-go, not a company-wide standard.

To engineering: The value is a shared vocabulary and pre-built tactical primitives — aggregate roots, entities, value objects, domain events — so we stop re-litigating the same scaffolding and reviewers get a concrete contract to check against. Constraints we're accepting: single maintainer, no downstream users, so we own our fork and our upgrade cadence; and the dependency stays inside the domain-model layer, with messaging and persistence on Symfony Messenger or Laravel's bus/queue. If the base classes are inheritance-heavy and don't match our composition preferences, we say no and steal the patterns instead — that's an acceptable outcome of the pilot. Success criteria for the pilot: one module shipped, measurable reduction in scaffolding code, and a review of whether the abstractions leaked into application code.