Tactician Doctrine Laravel Package

Product Decisions This Supports

• Command-bus architecture vs. plain service layer — Adopting this package is effectively a commitment to Tactician as the write-side entry point. It only pays off if the roadmap includes CQRS-lite / DDD-style command handlers, not just CRUD controllers.
• Transaction boundary ownership — The real product question it answers is where the unit of work begins and ends: in the controller, in the service, or in middleware around every command. This package encodes the third option, which is the most consistent and the least visible to feature teams.
• Build vs. buy for infrastructure glue — The functionality is small (middleware that begins a Doctrine transaction, invokes the handler, commits on success, rolls back on exception). A PM decision here is whether to take a dependency for ~100 lines of behavior or own an internal equivalent.
• Reliability roadmap for write-heavy domains — Billing, orders, inventory, entitlements: any surface where a partially-applied handler is a customer-visible defect. Transactional command handlers reduce the class of "half-written" states without per-feature code.
• Framework alignment — This is Doctrine ORM middleware, not Eloquent. It supports decisions in Symfony/Doctrine shops or Laravel apps running laravel-doctrine/orm; for Eloquent-native Laravel it is largely inapplicable and should not enter the roadmap as a Laravel dependency.
• Use cases worth naming: multi-step write commands (create order → reserve stock → emit event), back-office/admin actions needing all-or-nothing semantics, and incremental strangler migrations where a new command layer must sit alongside legacy persistence.

When to Consider This Package

Consider it when:

• You are already standardized on Tactician as the command bus and Doctrine ORM as the persistence layer — the package has no value outside that pair.
• Command handlers perform multi-step writes that must be atomic, and you want that guarantee by default rather than by convention.
• The team is small and comfortable reading middleware internals; the package is thin enough to audit in an afternoon.
• You treat it as vendored infrastructure: fork it, pin it, and add tests, because maintenance signals are weak (58 stars, 0 dependents, last release January 2022).

Look elsewhere when:

• You use Eloquent (Laravel's default). The Doctrine EntityManager is a hard requirement; use DB::transaction or job middleware instead.
• You use Symfony Messenger, which ships native Doctrine transaction middleware (doctrine_transaction) with active maintenance.
• You need vendor support, security SLAs, or PHP/framework version guarantees — the release cadence does not support that expectation.
• You have multiple data stores or external side effects in handlers. A database transaction will not make an HTTP call or a queued job roll back; you need outbox/saga patterns, not this.
• Handlers are long-running or do I/O. Wrapping them in a transaction increases lock duration and connection hold time — a scaling risk, not a safety win.
• You have no command bus and no plan to add one. Adopting the pattern to justify the package is the wrong direction.

How to Pitch It (Stakeholders)

For executives: This is a small piece of plumbing that makes multi-step write operations all-or-nothing by default, which reduces a category of data-integrity bugs in checkout, billing, and inventory flows. Cost is low and the license is permissive (MIT). The caveat is stewardship: the project is effectively dormant — 58 stars, no downstream dependents, no release since early 2022. We should not adopt it as a supported third-party dependency; if we want the behavior, we vendor or reimplement it internally so we own the risk. The decision is really "do we standardize a transactional command layer," and this package is a reference implementation for that decision, not a strategic bet.

For engineering: The package provides Tactician middleware — primarily a transaction middleware — that wraps command handler execution in a Doctrine transaction and commits or rolls back based on outcome. It is a handful of classes with no framework magic and no Laravel coupling; it assumes Tactician plus Doctrine ORM. Given the dormancy and the tiny surface area, my recommendation is to treat it as a specification: port the transaction middleware into our own codebase behind our command bus, cover it with tests, and avoid the dependency. If we are already on Tactician and Doctrine and want speed over ownership, pinning and forking is acceptable — but budget for the fork, because upstream fixes are not coming. If we are on Eloquent or Symfony Messenger, close this out; the equivalent capability already exists natively.