Open paaneko opened 1 month ago
Good idea, we can do it But let's use Application instead of UseCase directory because we depend on this repository https://github.com/CodelyTV/php-ddd-example/tree/main/src/Backoffice/Courses/Application
But if you do that, you will have a src/User/Application/Application
folder duplication, which looks kinda weird
It will look like src/User/Application/Confirm/Command.php Or src/User/Application/Confirm/Query.php Or src/User/Application/Confirm/CommandHandler.php
src/User/Application
├── ConfirmUser // here
├── DTO
├── EventListener
├── EventSubscriber
├── Factory
├── Message
├── MessageHandler
├── MutationInput
├── Processor
├── RegisterBatch //here
├── Resolver
├── SendConfirmationEmail //here
├── Transformer
└── UpdateUser // here
Yes, but IMHO this structure may look very sophisticated and might mislead some developers. Additionally, all CQRS handlers will be scattered across the Application layer, mixing with other already grouped structures such as Processor
, Resolver
, Transformer
, etc. Furthermore, if new CQRS handlers are added over time, it will lead to significant increasing number of folders.
I don't want to impose my view of DDD structure in your project, but I dare to ask your team to reconsider another approach or keep the current one :)
There are two common approaches to managing directories in a project: organizing by feature or use case, and organizing by programming patterns or classes. We primarily use the first approach, though we sometimes blend the two If you'd like to contribute, please feel free to submit comments with your ideas
I agree that for medium to large projects, the use case approach might be more suitable In the future, we could consider transitioning some of the project directories to a mixed approach
This change should reduce the number of folders in the
Application
layer and consolidate all CQRS commands in one place.