As a means of learning and gaining some experience with domain-driven design, I'm restructuring/refactoring an old application written in PHP which utilizes the Laravel 5.1 framework. Below is a mock-up of a simplified structure I came up with to begin my refactoring process which includes, in part, the default Laravel 5.1 'app' directory structure (found here). For clarity, the following statements may help clarify the provided structure:
- User represents an Aggregate Root.
- The domain directory underneath aggregate roots will contain any entities, events, exceptions and DAO/Repository interfaces.
- Although User does is not complex enough to subdivide its directories, certain AR's will be further broken down by aggregates in their respective Application, Domain, and Infrastructure directories.
Things I've specifically debated are:
- Where to place event listeners, (currently in Application directories).
- Where to place shared functionality, (currently in Core directory).
- Whether or not to include the Http and Console/Cli directories underneath each aggregate root directory, (currently keeping everything framework-specific in its default location).
- Whether to place Application/Domain/Infrastructure directories as top-level directories under ProjectName dir or (as I have done), place them underneath top-level AR directories.
Any tips and/or advice on best practices in DDD application structure is greatly appreciated.
app/
Console/
Exceptions/
Http/
Policies/
UserPolicy.php
ProjectName/
Core/
Application/
Domain/
Infrastructure/
User/
Application/
Listeners/
LogUserWasCreated.php
LogUserWasUpdated.php
Presenters/
UserProfilePresenter.php
Services/
CreateUserService.php
FindUserService.php
UpdateUserService.php
Domain/
Role.php
RoleDAO.php
User.php
UserDAO.php
UserNotCreated.php
UserNotFound.php
UserNotUpdated.php
UserWasCreated.php
UserWasUpdated.php
Infrastructure/
EloquentRoleDAO.php
EloquentUserDAO.php
Providers/
UserServiceProvider.php
alaric