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.

[JasperTey]

Hoping to resolve most of the items here in the PR currently in progress: #69

If you have a moment @pelmered, I wanted to understand your specific convention:

src/App/Api/Controllers/<domainName>/<modelName>ApiController.php

What is the root namespace of this application layer under src/App/**/*? Is Laravel's standard App\**\* namespace still intact or overridden?

[pelmered]

Hoping to resolve most of the items here in the PR currently in progress: #69

If you have a moment @pelmered, I wanted to understand your specific convention:

src/App/Api/Controllers/<domainName>/<modelName>ApiController.php

What is the root namespace of this application layer under src/App/**/*? Is Laravel's standard App\**\* namespace still intact or overridden?

Ok great job!
Yes, src/App/**/* is the normal App namespace.
I have all code in the src/ folder, and the folder structure there is:

src/App - The normal app folder. Application layer. API + Admin GUI (filament), middlewares etc.
src/Domain - All domain code and business logic
src/Integrations - First-party API clients and Integrations etc (No business logic allowed here)
src/Support - Global suport helpers/utility functions, traits, base classes, contracts, value objects, casts etc. 

The app folder is a bit of a mess with some code that is left there from the default Laravel structure. We plan to cleanup and refactor this a bit along with the a new API version. The other three are pretty well structured and some of the things in the App folder should probably be moved to support.

Regarding src/App/Api/Controllers/<domainName>/<resourceName>ApiController.php ( is typically 1:1 with a model, but not always), that is our current convention for the API. The admin code is in the src/App/Admin folder. The code for the new API will probably be in src/App/Api2/ but we haven't decided on much more than that yet, but I still think the current structure makes sense so we might keep some of it. I think maybe with invokable controllers for each action instead of one per API resource. As long as it is configurable in the DDD package and make the domain name part of the path, that would be great. Support for generating invokable controllers for CRUID actions would be nice, but that is something I could live without.

[JasperTey]

Thanks for the details @pelmered!

Here is the current implementation of the application layer in #69:

Application Layer (since 1.2)

Some objects interact with the domain layer, but are not part of the domain layer themselves. By default, these include: controller, request, middleware. You may customize the path, namespace, and which ddd:* objects belong in the application layer.

// In config/ddd.php
'application_layer' => [
    'path' => 'app/Modules',
    'namespace' => 'App\Modules',
    'objects' => [
        'controller',
        'request',
        'middleware',
    ],
],

The default configuration above will result in the following:

ddd:model Invoicing:Invoice --controller --resource --requests

Output:

├─ app
|   └─ Modules
│       └─ Invoicing
│           ├─ Controllers
│           │   └─ InvoiceController.php
│           └─ Requests
│               ├─ StoreInvoiceRequest.php
│               └─ UpdateInvoiceRequest.php
├─ src/Domain
    └── Invoicing
         └── Models
             └── Invoice.php

...which doesn't quite support your src/App/Api/Controllers/<domainName>/<resourceName>ApiController.php convention.

Would ALL controllers via ddd:controller or ddd:model --controller end up in src/App/Api/Controllers/**/*? Or only ddd:controller --api where the --api option is used?

I'm currently working on support for custom resolvers, but the caveat is that the point where namespaces are resolved, only the following information is available: domainName, resourceName, and type (via ddd:{type}). I'll think on this a bit and see if I can have more information made available for custom callbacks, such as the options that were used in the original ddd:* call.

[JasperTey]

Here is what I was able to implement so far (in #69):

// In config/ddd.php
'application_layer' => [
    'path' => 'src/App',
    'namespace' => 'App',
    'objects' => [
        'controller',
        'request',
        'middleware',
    ],
],

In AppServiceProvider boot method:

use Lunarstorm\LaravelDDD\ValueObjects\DomainCommandContext;

DDD::resolveNamespaceUsing(function (string $domain, string $type, ?DomainCommandContext $context): ?string {
    if ($type == 'controller' && $context->option('api')) {
        return "App\\Api\\Controllers\\{$domain}";
    }

    return null;
});

Result:

php artisan ddd:controller Invoicing:PaymentApiController --api

# Controller [src/App/Api/Controllers/Invoicing/PaymentApiController.php] created successfully.

Current Limitations:

• The custom resolver is only able to customize this portion of the full path: src/{App/Api/Controllers/Invoicing}/PaymentApiController.php.
• Laravel uses the name argument of the command (PaymentApiController) to produce the final fully qualified name by appending it to the resolved namespace.
• Might be able to overcome this at some point, but not so simple at the moment.

[JasperTey]

Closing in favour of #77