default ddd php project

Projet PHP DDD par défaut Avec Docker + PHPUnit + PHPCS + Symfony Flex (en tant qu'artefact d'infrastructure)

Squelette de base contenant uniquement un point de terminaison /_healthcheck et comprenant :

• Démarrage Dockerisé (avec PHP-FPM, vérifiez le dossier /docker et le README.md qu'il contient).
• PHPUnit (exécutez bin/phpunit pour réussir les tests unitaires).
• PHPCS (lien symbolique vers /vendor/bin/phpcs , exécutez bin/phpcs pour exécuter un renifleur de code basé sur la norme PSR2).

Si vous souhaitez inclure Redis dans votre projet, exécutez docker-compose -f docker-compose-with-redis.yml up -d

Exigences

Docker

Installation

1. Sur le dossier racine, exécutez : docker-compose up -d et attendez que tous les packages requis soient installés.
2. Entrez dans la machine ( docker exec -ti mylocalproject-php-fpm bash ) et exécutez une composer install depuis l'intérieur
3. Accédez à localhost:8000/_healthcheck, où vous devriez pouvoir voir ce résultat :

{
    "status" : " i am ok "
}

Maintenant, c'est à vous de décider comment vous voulez que votre projet se développe :)

Passer à la production

Si vous considérez l’environnement dockerisé comme suffisant pour la production, n’oubliez pas ces deux étapes :

1. Exécutez composer install --no-dev --optimize-autoloader --apcu-autoloader
2. N'oubliez pas de changer APP_ENV en pro dans le fichier .env .

Vous pouvez constater des performances raisonnablement bonnes en exécutant l'outil Apache Bench, avec environ 100 s de requêtes simultanées en 10 s : ab -n 100 -c 10 http://localhost:8000/_healthcheck

Architecture du projet

Ce projet est architecturé selon un pattern DDD + CQRS, qui contiendra trois parties principales :

• Domaine : représente les concepts métier et la logique métier. Il ne devrait rien savoir des autres parties.
• Application : définit les tâches et orchestre les objets du domaine pour résoudre les problèmes. Il peut simplement connaître Domain .
• Infrastructure : responsable des préoccupations Ui (Contrôleurs) / Console / Tiers. Cela peut connaître Application et Domain .

Structure du projet

Extension de l'architecture précédente, il s'agit de la structure de dossiers principale du projet.

 Domain
└─── Exception: Contains `AppException`, responsible for any exception about the application which
|                will contain an internal error code, plus a collection of `ErrorCodes` along the app
|                (important, taking into account that e.g. HTTP error codes sometimes are not informative enough)
|
└─── Model: Core business logic within the aplication, which will also contain validations for correctness.
|           In case that we use events through the system (e.g. creation, updates...) they would be placed here as well.
|           It will contain behavior and data, following[DomainModel](https://martinfowler.com/eaaCatalog/domainModel.html) Martin Fowler's pattern 
|
└─── Repository: Interfaces to access the data model that shall be viewed as a Collection,  with a composition as follows:
     └─── `findOfId`: Find a specific Model from a given unique ID. Ideally returns a Domain exception when not found
     └─── `findOfXxx`: Find the Model through an unique ID
     └─── `save`: responsible of create/update the model
     └─── `delete`: responsible of delete the model from the collection


Application
└─── Command: Executes an use case by orchestrating domain objects, and ideally produces an output in the shape of an event
|    └─── Request: Value objects representing a request per command
|
└─── Query: Implementation of specialized queries (anything different of a `findOfId`) to the model.
     |      Note: those are part of the Application because the Domain should not be aware at all about the expected Responses
     └─── Request: Value objects representing a request per query
     └─── Response: Set of Value Objects which we expect to obtain as a result of the query, ideally implementing a `Serializable`


Infrastructure
└───  EventListener: Even though those could be part of the Application layer (as actors regarding different events), 
|                    right now they are an infrastructure concern as the infra too is implemented as an Event schema.
|                    This could be different depending on your framework of choice (e.g. in Zend they would be middlewares)
|
└───  Repository: Contains folders with the different sources of implementation per repository (e.g, `MySqlUsersRepository`)
|
└───  Service: Third-party specific implementations of services and connectors (REST, MongoDB, Stripe...)
|
└───  Ui: Contains the user interface communication, mainly Console commands (cron/daemons) and Web commands (controllers)