lunarstorm/laravel-ddd

Toolkit for domain driven design (DDD) in Laravel. Provides artisan commands to generate domain models, DTOs, view models, value objects, and much more.

laravel-ddd's Issues

Base ViewModel not accounted for

The ddd:make:view-model command is not yet complete; the handling of base ViewModel is not yet accounted for, and currently leads to a incomplete generated view model.

Implement `HasDomainFactory` trait

Action item:

• Refactor the current domain model factory implementation as a portable HasDomainFactory trait instead

Discussed in #30

^{Originally posted by meditto August 17, 2023}
Hello, I hope you're all doing well. I've been using laravel-ddd for the past few days and have found it to be a valuable tool for my Laravel projects. I'd like to suggest a feature enhancement that I believe could further improve the package's usability.
The current process involves generating the BaseMdel. I believe this process could be simplified and made more user-friendly by introducing a new trait, HasDDDFactory.

The proposed HasDDDFactory trait would serve as a drop-in replacement for the existing HasFactory trait. It would automatically handle the detection of the appropriate factory path just like the BaseModel.

The flexibility of the HasDDDFactory trait could also extend to models that don't directly extend the Model object, such as the User model. This adaptability adds to its potential usefulness.

I would greatly appreciate your thoughts and insights on this proposal.

Support for Actions

I found myself wanting to generate domain Actions enough times that I think it's finally time to implement a corresponding ddd:action generator.

[1.x] Fix Base Models

This applies to the next branch only.

Observed an issue with ddd:view-model:

• appeared to always try to create a base view model even though one exists

% php artisan ddd:view-model Shared:TestViewModel
Base view model Domain\Shared\ViewModels\ViewModel doesn't exist, generating...

   ERROR  Base View Model already exists.  

   INFO  View Model [src/Domain/Shared/ViewModels/TestViewModel.php] created successfully. 

• view model stub incompatible with the refactored generator internals. Ends up inserting the import as

use Domain\\Shared\ViewModels\ViewModel;

with the extra slash. Should also create a failing test for this first before patching.

Publishable config and stubs

Ensure that package config and stub publishing is functional.

Autoloading issues

Hello again!

I'm having some issues with the autoloading. Primarily when deploying the code.

I like to put my related tests inside my domains (a command for generating tests would be great by the way), but that generates problems with the autoloading. The tests are only autoloaded when composer includes dev dependencies. But since theddd:cache command touches all files in the domain directory, this generates problems because the base test case is not autoloaded and thus I get this error: Class "Tests\TestCase" not found when running ddd:cache.

I created a repo where I demonstrate this problem here: https://github.com/pelmered/laravel-test-ddd
Just clone, run composer install --no-dev and then run ddd:cache to reproduce the problem.

I have also had problems with some other things, for example the migrations from babenkoivan/elastic-migrations. That package creates migrations with the same file format as the default Laravel migrations, but they also include a class name so they are not PSR autoload compliant. Here is how they look. When autoloading or running ddd:cache these files are included several times and therefore gives this kind of error: Cannot declare class CreateUsersIndex, because the name is already in use. I created a PR there to use anonymous classes, just like Laravels migrations, here.

As you can see, this is a general problem that probably needs to be addressed in this package in some way.
What do you think is the best way forward? Let me know if I can be of assistance.

Other than this, I'm happy to report that it worked very well in our application and that the transition was very smooth to start using the autoload provided in this package.

When configuring the domains path, namespaces are still using 'domains'

I updated my config to conform to my project file structure:

config/ddd.php

'paths' => [
        //
        // Path to the Domain layer.
        //
        'domains' => 'src/Domain',

I ran php artisan ddd:dto PurchaseOrder PurchaseOrderJobDetailsData and it put the file in the correct place (src/Domain/PurchaseOrder/Data).

The contents of the file are:

<?php

namespace Domains\PurchaseOrder\Data;

use Spatie\LaravelData\Data;

class PurchaseOrderJobDetailData extends Data
{
    public function __construct(
        // ...
    ) {
    }
}

Domain factories need `protected $model` to be defined

Followup: looks like the protected $model is needed for ddd usage after all... will work on a 0.6.1 to address this.

Originally posted by @JasperTey in #21 (reply in thread)

Message incomplete when creating base model

What is ? is likely supposed to be 'What is the name of the Base Model' or something similar but is cutting off early.

Additional Laravel 11 generators

Discussed in #53

^{Originally posted by JasperTey April 2, 2024}
Noting this down as a plan to add support for the rest of the new commands that were introduced in Laravel 11: https://laravel.com/docs/11.x/releases#new-artisan-commands

php artisan ddd:class
php artisan ddd:interface
php artisan ddd:trait

v1.0.0 added ddd:enum, but not the three above.

Implement support for model factories

It'd be nice to be able to do php artisan ddd:model -f and have it create the factory in the appropriate directory from the newFactory method in the BaseModel and have the protected $model attribute populated.

Originally posted by @funkymonk91 in #21

Allow configuring domain namespace

Action items:

• Introduce ddd.domain_path and ddd.domain_namespace config keys and deprecate the usage ddd.paths.

Discussed in #40

^{Originally posted by pelmered March 21, 2024}
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.

ddd:base-model and ddd:base-view-model insert the wrong domain

These commands are still hard coded to Domains and not what the configuration is set up for

ddd:model does not respect custom base model

When customizing ddd.base_model in config, ddd:model thinks it doesn't exist and attempts to generate one for you. It ends up being a malformed class generated in the root domain folder.