Ddd Laravel Package

Product Decisions This Supports

Standardize domain scaffolding, or let each squad roll its own. Every Laravel team eventually hand-writes base entity classes, value objects, and domain event plumbing. This package is a candidate standard. Frame the decision correctly: this is not a vendor selection, it is a fork-and-own decision. You are choosing whether one shared internal convention is cheaper than N divergent in-house ones — and whether this specific codebase should be the seed of that convention or just the inspiration for it.

Whether to fund architecture enforcement at all. The package's headline promise is "guard rails," but what ships is primitives — base classes, contracts, event recording, repository bindings. Actual enforcement (layer rules, dependency direction) comes from pairing it with architecture tests or tools like Deptrac/PHPArkitect. So the real product decision is a two-part one: do we want enforced boundaries, and is this the cheapest way to get the primitives? Treat "buy" as "adopt a starting point," not "acquire a capability."

When to split a modular monolith. DDD boundaries are the natural fault lines for future service extraction. If bounded contexts are explicit from day one, a later split is a refactor with a known seam rather than a rewrite. This package supports the decision to model boundaries now — but be honest that it does not itself prove boundaries hold. That requires CI checks you own.

Where to spend the architecture budget. Realistic high-return use cases: multi-tenant SaaS with genuinely rich business rules, legacy modernization where you want a clean seam before strangling old code, and platform teams building a shared Laravel starter kit. Low-return: CRUD back-office apps, prototypes, and products with under ~12 months of expected domain churn — the ceremony costs more than it returns, and the cost is paid in delivery velocity, not license fees.

Onboarding and outsourcing economics. Codified conventions compress ramp-up time for new hires and external teams. This is the number a PM can actually defend: reduced review friction and faster time-to-productive on a domain-heavy codebase. It supports headcount and vendor decisions at the point where domain complexity outgrows tribal knowledge.

Tech-debt sequencing and organizational appetite. A short spike is a cheap instrument for testing whether the team wants DDD discipline or merely wants tidier folders. That signal is worth the spike on its own, regardless of whether you adopt the package.

What this package does not decide for you. It won't tell you where transaction boundaries live, whether domain entities stay persistence-ignorant of Eloquent, or how domain events reach the queue. Those are product-adjacent architecture decisions that still need an owner and a written convention.

When to Consider This Package

Consider it when:

• The team has already committed to DDD or hexagonal architecture on the roadmap — guard rails accelerate a decision already made rather than manufacture one.
• You have, or credibly expect, two or more bounded contexts in one Laravel codebase and boundary violations recur in code review.
• You want the primitives (aggregate roots with event recording, value object equality, repository contracts) to be consistent across squads rather than reinvented per team.
• Someone will own a pinned fork: read the source, fix bugs, test Laravel major upgrades, adjudicate convention disputes.
• You are prepared to pair it with real enforcement — architecture tests in CI — because the package alone is convention, not compulsion.

Look elsewhere — or use it as a reference implementation rather than a dependency — when:

• Provenance is thin. Zero stars, zero dependents, single-org origin (a consultancy) reads as an extracted internal tool. You would be the first real adopter: no community to surface bugs, no track record across Laravel major versions, no release cadence to plan around. Verify license, test coverage, supported PHP/Laravel matrix, and last commit date before anything else.
• You need long-term support. No commercial backing means maintenance risk lands on your team. If nobody will own the fork, do not adopt.
• Simpler, more portable tools cover most of the value. Architecture tests (Pest/PHPUnit arch), Deptrac, or PHPArkitect deliver the enforcement; EventSauce, Broadway, or a ~200-line internal base class deliver the primitives. The enforcement idea is the valuable part and is largely reproducible without the dependency.
• The app is CRUD-shaped. DDD ceremony over a thin domain produces indirection with no payoff.
• Framework coupling is a risk. If the base classes drag Laravel internals into domain models, the package undermines the exact isolation it claims to enforce. Check this before committing.
• You're already on CQRS/Event Sourcing tooling. Overlap is high and this becomes a competing abstraction layer.

Gate before adoption: a two-week, one-squad spike on a real bounded context with a written pass/fail criterion — e.g. "80% of our domain rules are expressible without fighting the base classes, CI catches three seeded boundary violations, and one context can be lifted off the base classes in under a week." If it fails, keep the architecture-test patterns and drop the dependency; that is still a win.

How to Pitch It (Stakeholders)

For executives — one paragraph:

This is a small open-source library that gives our Laravel codebase structural guard rails for domain-driven design. The upside is internal and modest but real: consistent domain scaffolding across squads, architectural rules enforced in CI rather than debated in review, cheaper onboarding, and a cleaner path to splitting modules if we grow. The caveat is maturity — near-zero public adoption means we would be the first real adopter and would have to own a fork if we depend on it. Recommendation: fund a short, time-boxed spike, not a commitment. Treat it as an accelerator to validate, not a platform bet, and put no roadmap dependency on it until the spike closes.

For engineering — the honest framing:

It's opinionated scaffolding plus a set of contracts, not a framework. The genuine benefit is consistency and the pressure it puts on us to enforce boundaries in CI; the genuine cost is inheriting someone else's DDD dialect and inheriting the maintenance. We read the source first and confirm it doesn't smuggle Eloquent into the domain layer. Two weeks, one low-blast-radius context, an aggregate with invariants, a value object, a repository interface with an Eloquent adapter, and one domain event through Laravel's bus. Publish it as the reference implementation and write the convention doc — that doc is the load-bearing artifact, not the package. Worst case we keep the architecture-test patterns and the base classes we wrote and drop the dependency; that outcome is still a net gain.

The ask: one squad, two weeks, a written pass/fail criterion, and an explicit decision on whether we will maintain a pinned internal fork. No roadmap dependency until the spike closes.