default ddd php project

Standard-DDD-PHP-Projekt mit Docker + PHPUnit + PHPCS + Symfony Flex (als Infrastrukturartefakt)

Grundgerüst, das nur einen /_healthcheck Endpunkt enthält und Folgendes umfasst:

• Dockerisierter Start (mit PHP-FPM, überprüfen Sie den Ordner /docker und die README.md darin).
• PHPUnit (führen Sie bin/phpunit aus, um die Unit-Tests zu bestehen).
• PHPCS (Symlink zu /vendor/bin/phpcs , führen Sie bin/phpcs aus, um einen Code-Sniffer basierend auf dem PSR2-Standard auszuführen).

Wenn Sie Redis in Ihr Projekt einbinden möchten, führen Sie docker-compose -f docker-compose-with-redis.yml up -d aus

Anforderungen

Docker

Installation

1. Führen Sie im Stammordner Folgendes aus: docker-compose up -d und warten Sie, bis alle erforderlichen Pakete installiert sind.
2. Gehen Sie in die Maschine ( docker exec -ti mylocalproject-php-fpm bash ) und führen Sie von innen eine composer install aus
3. Gehen Sie zu localhost:8000/_healthcheck, wo Sie diese Ausgabe sehen sollten:

{
    "status" : " i am ok "
}

Jetzt liegt es ganz bei Ihnen, wie Ihr Projekt wachsen soll :)

Geht in die Produktion

Wenn Sie die Docker-Umgebung für gut genug für die Produktion halten, denken Sie an diese beiden Schritte:

1. Führen Sie composer install --no-dev --optimize-autoloader --apcu-autoloader aus
2. Denken Sie daran, APP_ENV in der .env Datei in pro zu ändern.

Sie können eine einigermaßen gute Leistung feststellen, wenn Sie das Apache Bench-Tool ausführen, wobei etwa Hunderte von Anfragen in 10 Sekunden gleichzeitig ausgeführt werden: ab -n 100 -c 10 http://localhost:8000/_healthcheck

Projektarchitektur

Dieses Projekt ist nach einem DDD + CQRS-Muster aufgebaut, das drei Hauptteile enthält:

• Domäne : repräsentiert Geschäftskonzepte und Geschäftslogik. Es sollte nichts über die anderen Teile wissen.
• Anwendung : Definiert Jobs und orchestriert Domänenobjekte, um Probleme zu lösen. Es kann einfach etwas über Domain wissen.
• Infrastruktur : Verantwortlich für Benutzeroberflächen (Controller), Konsolen und Dritte. Dies kann über Application und Domain Bescheid wissen.

Projektstruktur

Als Erweiterung der bisherigen Architektur ist dies die Hauptordnerstruktur innerhalb des Projekts

 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)