Add generators for seeders and migrations + Options to generate

[pelmered]

This PR adds commands for generating seeders and migrations inside the domain.

It also adds options on the ddd:model command to generate more files at the same time.

ddd:model -a also generates factory, seeder, migration and policy for that model. I thought that you also could configure what you want to have generated with this option in the config file
ddd:model -f also generates a model factory
ddd:model -m also generates a migration
ddd:model -p also generates a policy
ddd:model -s also generates a seeder

I also thought about adding -t to generate a test file. An option for generating PHPUnit or Pest class would be nice.

The migration command is currently not working properly and it needs some more testing.

[JasperTey]

Thanks! Is this an active fork being used in your project, or can I hop in and work on things?

[pelmered]

Thanks! Is this an active fork being used in your project, or can I hop in and work on things?

Yes, I use this in my local dev, but for the moment it is a local path repository in composer so you can commit to this branch and it will not effect me until I pull down the changes.

[pelmered]

@JasperTey Have to worked anything more on this? I might have some time in the weekend to look at this.

[JasperTey]

@JasperTey Have to worked anything more on this? I might have some time in the weekend to look at this.

I was also reserving the weekend for this. One recent thought that I'll share, from some experimentation on a local branch:

Making ddd:model extend Illuminate\Foundation\Console\ModelMakeCommand directly. In other words, this package would no longer publish model stubs etc, and instead wraps around the native make:model just like the other extended commands like ddd:enum. Domain factory auto-discovery makes this possible, and the native eloquent models generated into the domain layers will just work. Also simplifies the customization of options and inherit directly from make:model.

        return [
            ['all', 'a', InputOption::VALUE_NONE, 'Generate a migration, seeder, factory, policy, resource controller, and form request classes for the model'],
            ['controller', 'c', InputOption::VALUE_NONE, 'Create a new controller for the model'],
            ['factory', 'f', InputOption::VALUE_NONE, 'Create a new factory for the model'],
            ['force', null, InputOption::VALUE_NONE, 'Create the class even if the model already exists'],
            ['migration', 'm', InputOption::VALUE_NONE, 'Create a new migration file for the model'],
            ['morph-pivot', null, InputOption::VALUE_NONE, 'Indicates if the generated model should be a custom polymorphic intermediate table model'],
            ['policy', null, InputOption::VALUE_NONE, 'Create a new policy for the model'],
            ['seed', 's', InputOption::VALUE_NONE, 'Create a new seeder for the model'],
            ['pivot', 'p', InputOption::VALUE_NONE, 'Indicates if the generated model should be a custom intermediate table model'],
            ['resource', 'r', InputOption::VALUE_NONE, 'Indicates if the generated controller should be a resource controller'],
            ['api', null, InputOption::VALUE_NONE, 'Indicates if the generated controller should be an API resource controller'],
            ['requests', 'R', InputOption::VALUE_NONE, 'Create new form request classes and use them in the resource controller'],
        ];

Of course, each option would be generated as the corresponding DDD equivalent where applicable.

Would this be a welcomed change?

[pelmered]

Sure, that sounds good. How would we handle controllers, requests etc that maybe shouldn't be in the domain. Should they be generated in the Application layer then? If so, then I would like to be able to control where they are generated based on the information we have.

For example I typically have my controllers at this path in my application: src/App/Api/Controllers/<domainName>/<modelName>ApiController.php. At least all API controllers, so with the api flag they should end up there. Requests and Resources follow a similar pattern. I can investigate how hard this would be to support. That would be a great feature.

[JasperTey]

Sure, that sounds good. How would we handle controllers, requests etc that maybe shouldn't be in the domain. Should they be generated in the Application layer then? If so, then I would like to be able to control where they are generated based on the information we have.

For example I typically have my controllers at this path in my application: src/App/Api/Controllers/<domainName>/<modelName>ApiController.php. At least all API controllers, so with the api flag they should end up there. Requests and Resources follow a similar pattern. I can investigate how hard this would be to support. That would be a great feature.

Yeah, a configurable path for the application layer will be needed.

In my recent applications, there is often an equivalent "module" in the application that corresponds to a domain. Example:

• src/Domain/Invoicing/Models/Invoice.php
• app/Modules/Invoicing/Controllers/InvoiceController.php
• app/Modules/Invoicing/Controllers/SendInvoiceController.php
• app/Modules/Invoicing/Requests/UpdateInvoiceRequest.php

And there are also modules that could exist which don't correspond to any domain necessarily. e.g.,

• app/Modules/Settings/PreferenceController.php
• app/Modules/Dashboard/Controllers/AdminDashboardController.php

In these apps, I've created local commands that allow me to do the following:

php artisan make:controller InvoiceController --module=Invoicing
php artisan make:controller SendInvoiceController --module=Invoicing
php artisan make:request UpdateInvoiceRequest --module=Invoicing
php artisan make:controller PreferenceController --module=Settings
php artisan make:controller AdminDashboardController --module=Dashboard

Would new ddd config keys module_path and module_namespace be a suitable/neutral term to refer to this "other layer"?

Your example with src/App/Api/Controllers/<domainName>/<modelName>ApiController.php is highly specific, possibly too opinionated since make:controller does not change the controller naming convention whether or not --api is used. But maybe there can be an elegant way to customize this on an opt-in basis? I am open to ideas.

Let me know your thoughts.

[pelmered]

Yeah, a configurable path for the application layer will be needed.

In my recent applications, there is often an equivalent "module" in the application that corresponds to a domain. Example:

* src/Domain/Invoicing/Models/Invoice.php

* app/Modules/Invoicing/Controllers/InvoiceController.php

* app/Modules/Invoicing/Controllers/SendInvoiceController.php

* app/Modules/Invoicing/Requests/UpdateInvoiceRequest.php

And there are also modules that could exist which don't correspond to any domain necessarily. e.g.,

* app/Modules/Settings/PreferenceController.php

* app/Modules/Dashboard/Controllers/AdminDashboardController.php

In these apps, I've created local commands that allow me to do the following:

php artisan make:controller InvoiceController --module=Invoicing
php artisan make:controller SendInvoiceController --module=Invoicing
php artisan make:request UpdateInvoiceRequest --module=Invoicing
php artisan make:controller PreferenceController --module=Settings
php artisan make:controller AdminDashboardController --module=Dashboard

Would new ddd config keys module_path and module_namespace be a suitable/neutral term to refer to this "other layer"?

Your example with src/App/Api/Controllers/<domainName>/<modelName>ApiController.php is highly specific, possibly too opinionated since make:controller does not change the controller naming convention whether or not --api is used. But maybe there can be an elegant way to customize this on an opt-in basis? I am open to ideas.

Let me know your thoughts.

Yes, I think this could work for a general and not so opinionated use case. And I agree, my convention might be a bit too specific and opinionated to support in an easily configurable way.
I think a sensible default like you are suggesting would be good. Then I would like some kind of call back option to resolve path/namespace and possibly also file name.

Maybe something like:

DDD::resolveApplicationPathsUsing(function (string $fileName, string $fileType, string $domain) {
    return match($fileType) {
         'controller' => 'src/App/Api/'.$domain.'/Controllers/'.$fileName.'.php',
         'resource' => 'src/App/Api/'.$domain.'/Resources/'.$fileName.'.php',
    }
});

I can play around with this and see if I find something flexible and intuitive.

[JasperTey]

For this PR, will keep things simple and just extend make:model and let --controller and --request generate in the standard locations for now. The customizable module/application layer concepts can be developed further in a separate PR afterwards.

[JasperTey]

I started poking around on on this PR; I see a variety of other micro changes which I don't want to disrupt since this is being used in your project. I'm going to leave this PR intact for reference purposes, but will start work in a clean branch to focus on implementing ddd:model as an extension of make:model supporting all options.

Another idea I see you've implemented, is supporting ddd-specific stubs when present (Concerns\ResolvesStubPath). I like that, but will get that formalized in its own PR afterwards.

[pelmered]

I started poking around on on this PR; I see a variety of other micro changes which I don't want to disrupt since this is being used in your project. I'm going to leave this PR intact for reference purposes, but will start work in a clean branch to focus on implementing ddd:model as an extension of make:model supporting all options.

Another idea I see you've implemented, is supporting ddd-specific stubs when present (Concerns\ResolvesStubPath). I like that, but will get that formalized in its own PR afterwards.

Ok, that sounds good.
I'll see what I can build on top of that to support my case.

[JasperTey]

PR got closed when I deleted and recreated the develop branch... forgot that the branch was being used for this draft PR.