Domain Kata Laravel Package

Technical Evaluation

What this actually is. phpmentors/domain-kata is the PHP Mentors (Japan) "kata" — an exercise/reference artifact demonstrating DDD tactical building blocks in PHP. The v1.4.0 notes confirm the surface is broader than a minimal skeleton: alongside Entity, ValueObject, Identity, DomainEvent, DomainEventPublisher, DomainEventSubscriber, Repository, and Specification, it now ships UsecaseInterface, ServiceInterface (marker), InOutInterface, IdentifiableInterface, and EntityCollectionInterface::toArray(). It remains a teaching vocabulary, not an infrastructure library. That distinction drives every conclusion below, and the new release does not change it.

Architecture fit. Still framework-agnostic, PSR-0/PSR-4-era plain PHP — conceptually compatible with hexagonal/DDD layering inside a Laravel app, mechanically awkward. The release adds three points of friction rather than relieving any:

• InOutInterface extends EntityInterface — modelling Input/Output as a domain entity conflates a use-case DTO with an identity-bearing aggregate. Adopting this literally imports a design smell into the domain layer.
• ServiceInterface is an empty marker: zero compile-time or runtime enforcement, so it documents intent without guaranteeing anything. Laravel has no equivalent and needs none; it would be a naming convention only.
• EntityCollectionInterface::toArray() pushes a serialization/presentation concern into the domain collection. Convenient for the kata's demos, but a leakage vector we would not carry into a Laravel app where API resources own serialization.
• Unchanged: the static/global DomainEventPublisher still sits awkwardly against Laravel's container-bound dispatcher, and value objects remain hand-rolled rather than custom casts.

Integration feasibility. Unchanged and low as a Composer dependency. Critically, the release date is 2015-06-13 — identical to the last-release date already recorded in the assessment. This is not a new maintenance signal; it is confirmation that v1.4.0 is the terminal release. Eleven years without a subsequent tag, PHP 5.x-era constraints, PHPUnit 4 suite: composer require on Laravel 9–11 / PHP 8.2 will fail resolution or fatal on language-level incompatibility. Feasible only as a vendored/forked pattern source — and the added interfaces enlarge the set of things we would deliberately not copy.

Technical risk.

• License: NOASSERTION — highest-severity item, unchanged. No clear grant means no legal clearance to ship; treat as reference-only until counsel rules.
• Abandonment — now confirmed by the release history: v1.4.0 is the end of the line. No security response path, no PHP 8 compatibility, no maintainer.
• Adoption signal — 73 stars, 0 dependents; no ecosystem validation. Opportunity score 24.86 corroborates low strategic value.
• Global state — static event publisher remains a testability and lifecycle hazard.
• New: cargo-cult surface area — marker interfaces and a UsecaseInterface/InOutInterface pair invite teams to build ceremonial use-case plumbing (Input/Output objects, service markers) with no behavioural payoff, inflating the domain layer for no measurable gain.
• Documentation — PHP Mentors material is largely Japanese; the code is the documentation. The release notes, while in English, describe what was added, not why or when not to use it.

Key questions.

1. Is the intent to depend on this package or to learn from it? (Recommendation: the latter, exclusively — unchanged.)
2. Has legal reviewed the NOASSERTION license, and does that block even vendoring snippets? (Gate; still open.)
3. Which DDD concepts do we actually need? The release adds four more constructs to choose from — we should explicitly decline InOutInterface and ServiceInterface rather than inherit them by default.
4. Do we already have an internal domain-layer convention, or would this become it?
5. Who owns the fork, and what is the deprecation plan if we standardize on it?

Integration Approach

Stack fit. Unchanged in substance, with the release sharpening the mapping:

• ValueObject → PHP 8.1 readonly classes or Spatie\LaravelData/custom casts; drop the base class.
• Entity identity/equality, IdentifiableInterface → a small trait or abstract class with getId(); own implementation, no dependency.
• DomainEvent → Laravel native events + Event::dispatch after transaction commit; drop the static publisher.
• Repository → interfaces in Domain, Eloquent implementations in Infrastructure.
• UsecaseInterface / InOutInterface → do not port. Laravel's controller/action + FormRequest + API Resource stack already covers this ground with framework-native validation, authorization, and serialization. Recreating it in the domain layer duplicates the framework.
• ServiceInterface → do not port; a marker interface with no enforcement is documentation debt.
• EntityCollection::toArray() → do not port; serialization belongs to resources/transformers.

Net: the release nudges the superseded proportion above the previously estimated ~60%. Cherry-pick vocabulary, not code.

Migration path.

1. Legal ruling on license (gate — no code movement before this).
2. Read-only spike: fork the repo internally, tag reference/domain-kata-v1.4.0, no production dependency.
3. Rewrite the 5–8 useful classes in packages/domain (Composer path repository) with declare(strict_types=1), return types, PHPUnit 10 tests, README in English. Explicitly record the deliberate exclusions (InOutInterface, ServiceInterface, toArray(), static publisher) so future contributors don't reintroduce them.
4. Add an ADR recording "we adopt DDD tactical patterns, implemented in-house, based on PhpMentors kata v1.4.0, with the following exclusions…".
5. Pilot in one bounded context.

Compatibility. Target PHP 8.2+ / Laravel 10–11 / PHPUnit 10. Reject the upstream test suite and any Doctrine examples. Zero runtime dependency on the original package remains the success criterion. There is no upgrade path to plan for, because there will be no further upstream releases.

Sequencing. Unchanged and unaffected by the release: License → in-house base classes + tests → ADR (including exclusions) → single bounded-context pilot (2–4 weeks) → measure (domain-layer coverage, ORM leakage count, and now also ceremony ratio: lines of use-case/DTO scaffolding per unit of behaviour) → widen or stop. Do not sequence this as a platform-wide "DDD initiative" before the pilot proves value; the new interfaces make scope creep marginally more likely, not less.

Operational Impact

Maintenance. You inherit 100% of it. The maintained surface is small (single-digit classes), so steady-state cost stays near zero. Budget the initial modernization (est. 3–5 engineer-days including tests) — unchanged, since we are not porting the newly added interfaces. Treat upstream as dead and confirmed final. Pin the fork internally; never reference the public package in composer.json.

Support. No vendor, no SLA, no CVE process. Community support is the PHP Mentors blog/book corpus, primarily Japanese, and the v1.4.0 notes are terse English changelog entries rather than guidance. Plan for translation or an internal champion. Escalation path is "whoever wrote the fork."

Scaling. Code-level patterns do not constrain throughput; the package is not a runtime component. Organizational risks are unchanged — divergent copies of base classes unless distributed as a versioned internal package. The static event publisher, if adopted, risks duplicate dispatch and leaked listeners. The new InOutInterface/ServiceInterface pair adds a mild scaling hazard: each team left to interpret them will invent its own use-case ceremony, producing inconsistent layering across bounded contexts.

Failure modes.

• Procurement/legal discovers NOASSERTION post-integration → forced rip-out.
• Naive composer require → resolution failure or PHP 8 fatal, misdiagnosed as "package is broken."
• Cargo-culting: teams inherit base classes and now also use-case/DTO scaffolding without understanding invariants, producing anemic or over-abstracted models.
• Eloquent leakage into "entities," erasing the benefit.
• Serialization leaking into the domain via toArray()-style collection methods.
• Orphaned fork: no owner, drifts, quietly diverges.

Ramp-up. A senior PHP engineer reads the whole thing in 1–2 days; v1.4.0 adds maybe an hour of reading but a disproportionate amount of decision surface, because each new interface must be explicitly accepted or rejected. Team-level fluency in DDD tactical patterns remains the real cost: 2–4 weeks, best spent with the pilot team rather than as classroom training. Onboarding to the fork is trivial if the ADR and tests exist — and the ADR is now more valuable, since it must record what we chose not to take.

TPM recommendation. Do not adopt as a dependency. v1.4.0 is a 2015 terminal release re-confirming abandonment, not a maintenance signal; it expands the vocabulary but changes none of the risk posture. Use as a reference vocabulary and training artifact, explicitly scope out UsecaseInterface, InOutInterface, ServiceInterface, EntityCollection::toArray(), and the static publisher, fund a small in-house domain-layer package with the license question closed first, and gate broader rollout on the single-context pilot. Value delivered remains pedagogical and architectural, not operational — size the investment accordingly.