Poll: DDD Application Layer Structure

[JasperTey]

Looking for feedback on how others structure their application layer when working with DDD. i.e., objects that interact with the domain layer, but are not part of the domain layer themselves. Typically in the application layer are: controller, request, api resource. Although in my use cases, I consider api resource to be part of the domain as I tend to use them inside view models. For the purpose of this package, the goal is NOT to be opinionated and let developers configure as they wish.

Scenario

Generating an Invoice domain model with controller and requests, of which the controller and form requests will be generated in the application layer:

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

Output 1: Group by Domain

Schema: {{ ApplicationLayer }}/{{ Domain }}/{{ Type }}/{{ Class }}.php

app/Modules/Invoicing/Requests/StoreInvoiceRequest.php
app/Modules/Invoicing/Requests/UpdateInvoiceRequest.php
app/Modules/Invoicing/Controllers/InvoiceController.php

Output 2: Group By Type

Schema: {{ ApplicationLayer }}/{{ Type }}/{{ Domain }}/{{ Class }}.php

app/Modules/Requests/Invoicing/StoreInvoiceRequest.php
app/Modules/Requests/Invoicing/UpdateInvoiceRequest.php
app/Modules/Controllers/Invoicing/InvoiceController.php

Are there other structures entirely different than the above?

Sample Config

// In config/ddd.php
'application_layer' => [
    // The path to the application layer
    'path' => 'app/Modules',

    // The root namespace of the application layer
    'namespace' => 'App\Modules',

    // Customize the structure?
    'schema' => '{{ namespace }}/{{ domain }}/{{ type }}/{{ object }}',

    // Choose which ddd:* objects should end up in the application layer
    'objects' => [
        'controller',
        'request',
    ],
],

The v1.2 draft PR #69 implements Output 1: Group by Domain, with the following limitations:

• schema not yet configurable