default ddd php project
1.0.0
/_healthcheck
エンドポイントのみを含み、以下を含む基本スケルトン:
/docker
フォルダーとそこにあるREADME.md
を確認します)。bin/phpunit
を実行します)。/vendor/bin/phpcs
へのシンボリックリンク、 bin/phpcs
を実行して PSR2 標準に基づいたコード スニッファを実行)。プロジェクトに Redis を含める場合は、 docker-compose -f docker-compose-with-redis.yml up -d
を実行します。
ドッカー
docker-compose up -d
を実行し、必要なパッケージがすべてインストールされるまで待ちます。docker exec -ti mylocalproject-php-fpm bash
)、内部からcomposer install
実行します。{
"status" : " i am ok "
}
さて、プロジェクトをどのように成長させたいかは完全にあなた次第です:)
Docker 化された環境が運用環境に十分であると考える場合は、次の 2 つの手順を覚えておいてください。
composer install --no-dev --optimize-autoloader --apcu-autoloader
実行します。.env
ファイル内のAPP_ENV
忘れずにpro
に変更してください。 Apache Bench ツールを実行すると、10 秒間で約 100 のリクエストを同時に実行すると、かなり良好なパフォーマンスが得られます: ab -n 100 -c 10 http://localhost:8000/_healthcheck
このプロジェクトは DDD + CQRS パターンに従ってアーキテクチャ化されており、次の 3 つの主要な部分が含まれます。
Domain
について知ることができるだけです。Application
とDomain
について知ることができます。 以前のアーキテクチャを拡張したもので、これはプロジェクト内のメインのフォルダー構造です。
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)