This documentation details the architecture and inner workings of the laravel_module_create library, designed to automate module creation within the Laravel ecosystem, following Domain-Driven Design (DDD) principles and facilitating the adoption of Test-Driven Development (TDD).
The library utilizes a modular architecture based on Actions, allowing for a clear separation of concerns and facilitating maintenance and testability.
The modules generated by the library follow a structure organized by domain within app/MyProject/:
- Controllers: Management of HTTP requests.
- Models: Data representation and essential business rules.
- Providers: Service registration and bindings within the Laravel Service Container.
- Requests: Input data validation.
- Resources: Model transformation for API responses (Eloquent Resources).
- Routes: Definition of domain-specific endpoints.
- Services: Complex business logic layer, isolating the Controllers.
The library in src/ utilizes:
- Action Pattern: Each task (e.g., creating a file, processing a template) is encapsulated in an Action class within
src/Actions. - Command Pattern: Command-line interface (CLI) via
src/Commands, utilizing thesymfony/consolecomponent. - Template Engine: Use of stub files in
src/Templatesfor dynamic code generation.
- Input: The user executes a command via Console (e.g.,
php artisan module:create Customer). - Configuration Processing: The library reads configurations in
src/Configand identifies the target path. - Action Execution:
- Validation of the module name.
- Mapping of required directories.
- Reading of templates (
src/Templates). - Placeholder substitution (e.g.,
{{moduleName}},{{namespace}}).
- File Writing: Physical creation of classes and directories in
app/MyProject/[Module]. - Registration: (Optional) Automation of the new
ServiceProviderregistration in Laravel'sapp.php.
To ensure robustness, the library was structured to support rigorous testing using PHPUnit.
Focus on the isolated logic of Actions and Helpers.
- What to test:
- Whether the
NameFormattercorrectly transforms "customer_orders" into "CustomerOrders". - Whether validation Actions reject invalid module names.
- Whether the
- Example flow:
- Create a test for a new formatting Action.
- The test fails.
- Implement the logic in the Action.
- The test passes.
Focus on the complete command and the final result in the filesystem.
- What to test:
- The execution of the
module:createcommand. - Verification that all files (Controller, Service, etc.) were created in the correct paths.
- Verification that the content of the generated files has the correct Namespace and class names.
- The execution of the
- Useful tools:
- Use of
Illuminate\Support\Facades\Fileto mock or verify the filesystem. $this->artisan('module:create', ['name' => 'TestModule'])->assertExitCode(0);
- Use of
- PHP 8.0+
- Laravel Framework (Illuminate Components): For support with Collections, Filesystem, and Service Container.
- Symfony Console: For the CLI interface.
- PHPUnit 12+: For the automated test suite.
- Carbon: For date manipulation if needed in stubs/logs.
To add a new component to the module generation (e.g., Repositories):
- Create the stub in
src/Templates/Repository.stub. - Create a
CreateRepositoryActionAction insrc/Actions. - Register the new Action in the main command within
src/Commands. - Add the test case in
tests/Feature/CustomerFeatureTest.php.