hlogeon/LaravelBoilerplate

Boilerplate for Laravel Framework apps

Laravel DDD boilerplate

Important libraries included

• Dingo API - helps to create API's
• CodeCeption - Acceptance, Unit and Functional testing
• Doctrine MongoDB ODM - Object Document Mapper(can be replace with ORM, take a look at replacements bellow)
• Swagger - API documentation tool
• L5-Swagger - Swagger integration for Laravel. Adding support of generating APIDocs from PHP Annotations using Doctrine Annotations

Architecture notes

1. Code of application is inside app/ folder.
2. Configuration files are in config/ folder. Environment-specific configuration(such as database connections, email providers etc) should be set in .env file. Example of .env file can be find in the root of the project .env.example
3. This boilerplate is using 3-layer DDD architecture and the layers are

• Application(mixed with Interfaces layer) - The application layer is responsible for driving the workflow of the application, matching the use cases at hand. These operatios are interface-independent and can be both synchronous or message-driven. This layer is well suited for spanning transactions, high-level logging and security.The application layer is thin in terms of domain logic - it merely coordinates the domain layer objects to perform the actual work.
• Infrastructure(called Core in our case) - In simple terms, the infrastructure consists of everything that exists independently of our application: external libraries, database engine, application server, messaging backend and so on. Also, we consider code and configuration files that glues the other layers to the infrastructure as part of the infrastructure layer. Doctrine configuration and mapping files and implementations of the repository interfaces are part of the infrastructure layer.
• Domain - The domain layer is the heart of the software, and this is where the interesting stuff happens. There is one package per aggregate, and to each aggregate belongs entities, value objects, domain events, a repository interface and sometimes factories. The structure and naming of aggregates, classes and methods in the domain layer should follow the ubiquitous language, and you should be able to explain to a domain expert how this part of the software works by drawing a few simple diagrams and using the actual class and method names of the source code.

Replacements

You can replace packages from this boilerplate as you want. Common changes are:

1. Replace Doctrine ODM with Doctrine ORM
2. Add Laravel Passport for Auth
3. Use MySQL instead of MongoDB
4. Add migrations support (just create database/migrations folder) and use migrations as described in Laravel Documentationor Doctrine2 migrations.