- What is smorken/domain used for?
- smorken/domain is a Laravel package of domain-driven design helpers. It provides a starting point for organizing domain logic and keeping business rules separate from framework and infrastructure concerns. It is best treated as one author's reference implementation of DDD conventions rather than a canonical standard for Laravel.
- How do I install smorken/domain from Bitbucket in a Laravel project?
- Because the repository is Bitbucket-hosted and not published on Packagist, you add it to composer.json as a VCS repository entry. Every developer machine and CI runner then needs Bitbucket credentials, such as an app password or SSH key, to resolve the package. Pin the dependency to a commit SHA rather than a branch because no upstream branch protection is implied.
- Is smorken/domain available on Packagist?
- There is no indication that smorken/domain is published on Packagist, and the Bitbucket repository is the stated source. A standard composer require will not find it unless you configure a VCS repository or an internal mirror. Being outside Packagist also means it is excluded from normal composer audit advisory feeds.
- Which Laravel and PHP versions does smorken/domain support?
- Supported Laravel and PHP versions are not documented in the available information, so the constraints in composer.json are the only authority. Check PSR-4 autoload roots and the illuminate/support constraint against your current and next Laravel major. A smoke test in a throwaway Laravel skeleton is the most reliable way to confirm compatibility.
- Is smorken/domain safe to use in production?
- The package has no visible adoption signals: zero stars, zero dependents, and no evidence of production use. That does not mean the code is bad, but it means you will likely be the first to hit bugs. Confine it to the domain layer and review its service provider for unconditional bindings or config publishing before adopting.
- Does smorken/domain have a test suite or CI pipeline?
- No test suite or CI pipeline is evident from the available repository information. Without tests, every Laravel or PHP upgrade becomes a manual regression hunt across the abstractions the package provides. Verify this directly in the repository before committing to runtime use.
- What license is smorken/domain released under?
- You must check the repository for a LICENSE file. If no license is present, default copyright applies, which means you have no legal right to use or fork the code. Resolve licensing before any internal mirroring or redistribution.
- Should I use smorken/domain or write my own DDD helpers?
- Packages in this category are often only a few hundred lines of base classes, contracts, and scaffolding, so build-versus-buy often collapses toward build. DDD in Laravel has no canonical implementation, and teams differ on aggregate boundaries, repository return types, and domain events. Use the package as a pattern catalog unless its conventions closely match yours.
- Can I fork smorken/domain and maintain it internally?
- Technically yes: it is plain PHP with PSR-4 autoloading, so forking is straightforward once licensing is confirmed. Mirror it to an internal GitHub or GitLab repository, tag an internal release, and serve it through Private Packagist, Satis, or a path repository. This removes the Bitbucket credential dependency from your build path.
- What are alternatives to smorken/domain for DDD in Laravel?
- There is no single dominant DDD helper package for Laravel, so alternatives include other opinionated DDD packages, framework features such as events and the service container, or a small in-house domain layer. Evaluate alternatives on the same criteria: license, Laravel version constraints, tests, and distribution channel. Many teams ultimately build a minimal set of base classes tailored to their own conventions.