Krakboem Laravel Package

Technical Evaluation

Architecture fit: Krakboem is a small, framework-agnostic CQRS/event-sourcing toolkit consisting primarily of interfaces plus a handful of concrete classes. From a Laravel standpoint this is a double-edged sword: it does not entangle domain code with Eloquent, facades, or service providers, which is exactly what you want for aggregates and events that must outlive the framework. The trade-off is that none of Laravel's affordances (queue dispatching for async projections, ServiceProvider bindings, config publication, Artisan commands for replaying the event stream) are provided out of the box — every glue layer is on us. Compare to spatie/laravel-event-sourcing or eventsauce/*, which ship Laravel packages and documented wiring; Krakboem sits one abstraction level lower, closer to Broadway.

Integration feasibility: With zero stars and zero dependents, there is essentially no public evidence of this package running in a production Laravel application. The package appears to be the internal backbone of the RVA vzw (a Flemish non-profit; "krakboem" is Dutch and the docs/code comments are likely Dutch-first). Feasibility is therefore not judged on "does it work" but on "how much source review can we afford before we commit." The good news is scope: interfaces and a few classes means the surface area we must audit is small — we can read the whole thing in an afternoon and, if necessary, vendor it into our repo.

Technical risk (High):

• Bus factor = 1 org. Active development and maintenance are tied to a single non-profit's operational needs. No release cadence, no published roadmap.
• No adoption signal. 0 stars, 0 dependents, no downstream issue reports. Bugs are not being surfaced organically, which suggests the code is either very simple or very untested — likely both.
• Version/compat opacity. We have no confirmed PHP version range, no PSR-4/PSR-11 guarantees, no Laravel version compatibility matrix, and no known SemVer posture. Any composer require is a leap of faith.
• Interface-first design is a contract risk. If the vendor changes an interface signature in a "minor" release, every consumer breaks silently at container-resolution time rather than at compile time.
• The 9.65 opportunity score is a trap in this context. Low adoption frequently scores as "high opportunity" in maturity heuristics; it is not evidence of quality. Treat it as "unclaimed territory," not "proven gem."
• No visible event store. CQRS/ES correctness hinges on the event store, optimistic concurrency, and projection checkpoints; the description does not claim any of this is solved for us.

Key questions before any design work:

1. What exactly is concrete vs. interface? Specifically: is there an EventStore, an AggregateRoot, a Projector, a CommandBus, or only the contracts for these?
2. What does composer.json say — PHP range, dependencies, license (AGPL is common for vzw projects and would be a blocker for proprietary use), autoload config?
3. Is there any test suite? What does coverage look like for the concrete classes?
4. What is the event serialization strategy (JSON? serialize()? upcasting? schema versioning)?
5. How are projections checkpointed and replayed — is that our problem or the package's?
6. Is RVA vzw willing to accept PRs and cut releases, or do we effectively own a fork from day one?
7. Are the docs Dutch-only, and is that acceptable for the delivery team?

Integration Approach

Stack fit: Laravel is a workable host for CQRS/ES, but it is a passive host — nothing in the framework enforces or assists the pattern. Krakboem's value proposition fits naturally into a bounded context inside a larger Laravel monolith (e.g., reservations, memberships, ticketing), where the write side is event-sourced and the read side is ordinary Eloquent projections. It does not fit as a framework-wide rewrite of an existing Laravel CRUD app.

Migration path: Two viable routes.

• Greenfield bounded context. New module, new DB schema (events + projection tables), Krakboem as the domain core, Laravel as the transport and read-model layer. Lowest risk; recommended pilot.
• Brownfield strangler. Introduce an event stream alongside existing Eloquent tables, dual-write during transition, and rebuild read models from events once parity is proven. Higher coordination cost and requires an audit trail discipline the team may not have today. Not recommended until the greenfield pilot has shipped.

Compatibility: Unverified. Before anything else we must pin a commit (not a version constraint) and run composer why-not-style checks against our PHP and Laravel versions. Assume we will need a Composer repositories entry pointing at a fork.

Sequencing:

1. Audit sprint (timeboxed): read the full source, run composer install in a scratch project, inspect license, PHP range, test coverage, and Dutch docs.
2. Decision gate: fork-and-own vs. adopt-and-vendor vs. reject in favour of spatie/laravel-event-sourcing or eventsauce. Explicitly document why Krakboem over the established alternatives — if the answer is "nothing," reject.
3. Fork + harden: pin the fork, add missing bindings (service provider, CommandBus/QueryBus interfaces mapped to Laravel's container), add PHPUnit/Pest tests for any concrete class we depend on.
4. Event store decision: choose one explicitly (custom DB tables with a version column, or a real store). Krakboem will not decide this for us.
5. Pilot one aggregate end-to-end: command → aggregate → event → projection → read model → HTTP endpoint. Prove replay and concurrency handling.
6. Observability layer: structured logging on the command bus, projection lag metrics, dead-letter handling for failed projectors.
7. Expand only if the pilot held.

Operational Impact

Maintenance: We should plan to own the code. Even if RVA vzw is responsive, a single-maintainer non-profit cannot meet an enterprise SLA. Budget roughly 4–8 engineer-days to fork, add the Laravel glue (provider, config, Artisan commands for replay/snapshot), and write the missing tests — that is the true cost of "free." Ongoing maintenance is low if the interface surface is small, which is the package's main saving grace.

Support: There is no community, no Stack Overflow tag, no Discord, no issue history to learn from. Support is a direct message to a small Belgian non-profit. Documentation is likely Dutch-only and oriented at the authors, not at external adopters. The team must treat the source as the specification.

Scaling: Krakboem itself will not be the scaling bottleneck — CQRS/ES scaling is a function of event store throughput, projection strategy, and snapshotting, none of which the description claims to solve. The risk is subtler: without opinionated scaffolding, each team member invents their own replay, checkpoint, and upcasting strategy, and the codebase drifts into inconsistent patterns across bounded contexts. Architectural governance matters more than the library here.

Failure modes:

• Silent drift on interface changes. A renamed method surfaces at runtime, not at build time. Mitigation: pin to a commit hash, not a tag; vendor the package.
• Event schema evolution. No evidence of an upcaster/versioning mechanism. Mitigation: enforce a convention on day one (event name + explicit schema version) before the first event is written.
• Projection rebuild outages. Long replays blocking the read side. Mitigation: separate projection workers, replay in a shadow table, cut over.
• Concurrency. Optimistic-concurrency handling is not visible in the description. Mitigation: verify in the pilot with a concurrent-command test.
• Abandonment. The org pivots, the repo goes cold. Mitigation: internal fork is the plan, not the contingency.

Ramp-up: The real cost is not learning Krakboem — the surface is small — it is learning CQRS and event sourcing properly. Expect 2–4 weeks before a mid-level engineer ships a correct aggregate, and longer before the team reliably handles projection rebuilds, idempotency, and event versioning. The package provides almost no guardrails against the classic mistakes (fat aggregates, projections that mutate multiple read models, events that leak framework types), so a senior engineer familiar with ES must own the design review for the first two or three aggregates. Onboarding new hires is harder than a CRUD Laravel app because the mental model — commands in, events out, read models derived — is not what Laravel tutorials teach. The package's minimalism is a strength for experienced teams and a liability for teams learning the pattern on the job.