- What is geekcell/ddd and what does it actually include?
- GeekCell DDD is a lightweight Composer package that provides reusable building blocks for applying Domain-Driven Design in Laravel and plain PHP applications. It includes base classes and contracts for entities, value objects, aggregates, and domain events, plus repository abstractions for persistence boundaries. It also ships Laravel-friendly integration, including an auto-discovered service provider, while aiming to keep domain logic independent of the framework. Treat it as scaffolding and conventions rather than an enforcement tool.
- How do I install geekcell/ddd in a Laravel application?
- Install it with Composer using composer require geekcell/ddd. The package has no migrations, infrastructure footprint, or operational surface, and its Laravel service provider is auto-discovered. The real effort is not installation but deciding how your existing models map onto the provided contracts, which is a refactor rather than a drop-in change.
- Which PHP and Laravel versions does geekcell/ddd support?
- The available context does not state a formal support policy or a published PHP and Laravel compatibility matrix. Check the package's composer.json constraints, CI status, and recent release history before adopting it. Because there is no track record across Laravel major upgrades, plan to validate compatibility yourself and treat the dependency as fork-and-own.
- Does geekcell/ddd enforce domain-driven design rules or just provide scaffolding?
- It provides base classes and contracts for entities, value objects, aggregates, repositories, and domain events; it does not describe CI-checkable architecture rules, a PHPStan plugin, or shipped architecture tests. That makes it scaffolding rather than enforcement. If you need to prevent architecture drift, pair it with Pest arch tests, Deptrac, or PHPArkitect, because those tools enforce boundaries rather than suggest them.
- Should my domain entities be separate from Eloquent models when using geekcell/ddd?
- The package is explicitly Laravel-native but is designed to keep domain logic isolated from framework and infrastructure concerns through repository abstractions. In practice you must decide whether domain entities are distinct from Eloquent models or whether Eloquent is allowed to leak into the domain layer. If Eloquent creeps into entities, the persistence ignorance the package claims erodes silently under deadline pressure, so make this decision explicitly before retrofitting an existing application.
- How does geekcell/ddd handle aggregates and domain events?
- The package supplies an aggregate root base class that records and releases domain events, along with contracts for domain events themselves. In a Laravel application you can dispatch released events through Laravel's event bus, but you still define the event classes and decide where transactions begin and end. Aggregate boundaries and transaction scope remain design decisions the package does not make for you.
- How do I test a domain model built with geekcell/ddd?
- The provided primitives are plain PHP base classes and contracts, so value objects and aggregates can be unit tested with PHPUnit or Pest without booting Laravel. Repository interfaces can be faked or stubbed at the boundary, which keeps domain tests fast and isolated from the database. Use Pest architecture tests or Deptrac in CI to enforce that domain code does not depend on framework or infrastructure namespaces.
- Is geekcell/ddd safe to use in production and who maintains it?
- The package has zero stars, zero dependents, and a single-org origin, with no community to surface regressions and no stated support policy. That does not make it unusable, but it means you are effectively the first real adopter and should model it as fork-and-own from day one rather than as a vendor dependency. Confirm the license permits internal forking and check maintainer responsiveness to issues and pull requests before committing.
- When is geekcell/ddd a bad fit for a Laravel project?
- It is a poor fit for CRUD-shaped back-office apps, prototypes, single-squad products with low domain churn, and microservices too small to justify aggregates. It is also risky for teams with no engineer who has shipped a DDD codebase, because the package supplies rails but not judgment. Base-class inheritance is invasive, and contorting a domain to satisfy someone else's aggregate root can produce a worse design than the one you started with.
- What are the alternatives to geekcell/ddd for DDD in Laravel?
- For CQRS and event sourcing, EventSauce and Broadway are established frameworks that geekcell/ddd does not replace and may conflict with. For architecture enforcement, Pest arch tests, Deptrac, and PHPArkitect cover the guard-rails role the package leaves open. Many teams also hand-roll the primitives, which is often only a few hundred lines of internal code, so weigh that against adopting a low-traffic dependency.