Specify domain base namespace

[pelmered]

First of all, thank you so much for this package. I've been looking for something more lightweight land flexible like this for generating classes with support for DDD, but not do a lot more things and force me into opinionated ways to structure my code. This looks really great! There are just some generator commands that I am missing, like jobs, commands, enums, controllers or service providers, but I guess I could extend this package myself. Or do you have plans for adding some of this? I could send PRs for that.

Now for my current main issue.
I have my Domains at src/Domains but the namespace is just Domain\*. This is accomplished with this PSR-4 autoload directive: "Domain\\": "src/Domains/",
When I check in the code the namespace is just based on the configured domain path. I would like to be able to configure the namespace specifically.

I can make a PR for this if you want, but I'm not sure what the plan/purpose with the paths array in the config file. Why is this an array? To keep the support for setting multiple paths and have a reasonable structure of the config file, I think you have the break the backwards compatibility. For example like this in my case:

    'paths' => [
        'domains' => [
            // Base path to the Domain layer.
            'path' => 'src/Domains',
            // Base namespace for the domain layer.
            'namespace' => 'Domain',
        ]
    ],

This would also allow for more options here later without breaking backwards compatibility.

Let me know what you think.

[JasperTey]

Hey Peter!

Thanks for commenting... going to spill a bunch of my thoughts below:

First of all, thank you so much for this package. I've been looking for something more lightweight land flexible like this for generating classes with support for DDD, but not do a lot more things and force me into opinionated ways to structure my code. This looks really great! There are just some generator commands that I am missing, like jobs, commands, enums, controllers or service providers, but I guess I could extend this package myself. Or do you have plans for adding some of this? I could send PRs for that.

I would like to expand the generator coverage, yes. I am also rounding the corner on a v1.0 spec, and started scribbling down a roadmap here some time back: https://github.com/orgs/lunarstorm/projects/5 - in there you'll see I've noted down some of the same items above. Now, you mentioned "controllers" - in the spirit of DDD as I understand it, controllers should be kept out of the domain's responsibility since it's part of the HTTP layer. What is your use case for needing this?

Now for my current main issue. I have my Domains at src/Domains but the namespace is just Domain\*. This is accomplished with this PSR-4 autoload directive: "Domain\\": "src/Domains/", When I check in the code the namespace is just based on the configured domain path. I would like to be able to configure the namespace specifically.

Interesting. I have thought of making the namespace configurable instead of strictly being inferred by the path. I just hadn't heard feedback from anyone who required it yet. Curious: what's your reasoning for not keeping the folder and namespace aligned?

I can make a PR for this if you want, but I'm not sure what the plan/purpose with the paths array in the config file. Why is this an array? To keep the support for setting multiple paths and have a reasonable structure of the config file, I think you have the break the backwards compatibility. For example like this in my case:

    'paths' => [
        'domains' => [
            // Base path to the Domain layer.
            'path' => 'src/Domains',
            // Base namespace for the domain layer.
            'namespace' => 'Domain',
        ]
    ],

This would also allow for more options here later without breaking backwards compatibility.

Let me know what you think.

paths is an array because in an early iteration, there was another "module" path in there (which was an experimental thing from my own use cases, and ultimately too opinionated for this package). I'm leaning towards two top-level config keys ddd.domain_path and ddd.domain_namespace, and keeping the paths array intact but deprecated.

Some of my other thoughts, and more for the v1.0+ target:

• Thinking of moving to a more fluent way of configuring things in a published service provider instead of the config file
• In general, as more ddd:<things> are introduced, I don't really like the idea that ddd-specific generators have to exist to essentially mirror Laravel's make:<things>. I have a proof-of-concept of a generator command in a couple of my ongoing client projects, which instead proxy to Laravel's existing make commands and adjust the location/namespaces accordingly. I still need to refine the internals of that further. It would then allow this package to be even less opinionated and simply be a ddd:<whatever-laravel-can-make>, thereby allowing any DDD taboo to be crossed at your own discretion (such as "controllers" 😉).

Happy to hear more thoughts. I will work on a few minor updates this weekend to address the items above.

[pelmered]

Thank you for a great answer!

Yea, I have my controllers outside my domains. I'm not sure why I included that in the list 😅
But I have seen other people having controllers and routes in their domains.

Interesting. I have thought of making the namespace configurable instead of strictly being inferred by the path. I just hadn't heard feedback from anyone who required it yet. Curious: what's your reasoning for not keeping the folder and namespace aligned?
To be honest, it was a while back by now and I didn't put so much thought into it. I think the reasoning was that the folder Domains is where all the domains are, but it looked nicer with just Domain\Payments\etc... when using the namespaces. You only reference one domain at a time. I kind of like it like that now. But I was thinking about changing the namespace to Domains\ now after I installed this package, but I would prefer if it could be avoided for a few different reasons.

paths is an array because in an early iteration, there was another "module" path in there (which was an experimental thing from my own use cases, and ultimately too opinionated for this package). I'm leaning towards two top-level config keys ddd.domain_path and ddd.domain_namespace, and keeping the paths array intact but deprecated.

Ah ok, that makes sense. Yes, I think ddd.domain_path and ddd.domain_namespace would be the best solution. It's also smart as it allows to keep the paths array as it is.

I'm not sure a published service provider would be better, but I have no strong feelings either way.
Proxying the laravel commands sounds really great! I guess that would also work for third party make commands, lie the ones form Filament for example.
The roadmap for 1.0 sounds great as well. I'd love to help you out if you need.

[pelmered]

I was thinking about this some more. I have already implemented auto discovery/autoloading of service providers, policies, commands and factories inside each domain for my project. I could adapt and add most of the in this package. I think it would be a good fit.

Some other suggestions that I think would be great for version 1.,0:

• A command for creating a new domain with the proper directory structure and it could also include some files, like a service provider.
• Turn the domain prompt when creating a file into a select with the available domains by scanning the domain path.

I could provide PRs for this if you like the ideas.

[JasperTey]

I like these ideas; I will work on an initial v1 branch first, and then we can go from there...

[JasperTey]

A v1.0 draft is underway: #46

Feel free discuss further there, or PR against the next branch if your ideas are simple enough to flesh out for v1.0. Otherwise it can also be a v1.x thing. About the Laravel Prompts capability for more interactive console behaviour; it's only available from Laravel 10.17.0 onwards. There'd need to be a graceful fallback for <10.17, but I'm thinking v1.0 should require laravel 10.17 minimum to avoid all that hassle.

[pelmered]

As you will drop support for Laravel 9, I don't see a problem with requiring version 10.17 of Laravel instead of 10. Especially if this could be motivated with something like this. If you had reasons to support Laravel 8 or 9 it would be a different story IMO.