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