default ddd php project

Docker + PHPUnit + PHPCS + Symfony Flex를 사용하는 기본 DDD PHP 프로젝트(인프라 아티팩트)

/_healthcheck 엔드포인트만 포함하고 다음을 포함하는 기본 뼈대입니다.

• Docker화된 시작(PHP-FPM을 사용하여 /docker 폴더와 거기에 있는 README.md 를 확인하세요).
• PHPUnit(단위 테스트를 통과하려면 bin/phpunit 실행하세요).
• PHPCS( /vendor/bin/phpcs 에 대한 심볼릭 링크, bin/phpcs 실행하여 PSR2 표준 기반 코드 스니퍼 실행)

프로젝트에 Redis를 포함하려면 docker-compose -f docker-compose-with-redis.yml up -d 실행하세요.

요구사항

도커

설치

1. 루트 폴더에서 docker-compose up -d 실행하고 필요한 모든 패키지가 설치될 때까지 기다립니다.
2. 머신에 들어가서( docker exec -ti mylocalproject-php-fpm bash ) 내부에서 composer install 실행하세요.
3. localhost:8000/_healthcheck로 이동하면 다음 출력을 볼 수 있습니다.

{
    "status" : " i am ok "
}

이제 프로젝트가 어떻게 성장하기를 원하는지는 전적으로 귀하에게 달려 있습니다. :)

생산에 들어갑니다

Docker화된 환경이 프로덕션에 적합하다고 생각한다면 다음 두 단계를 기억하세요.

1. composer install --no-dev --optimize-autoloader --apcu-autoloader 실행
2. .env 파일 내에서 APP_ENV pro 로 변경하는 것을 잊지 마세요.

Apache Bench 도구를 실행하면 10초에 약 100개의 요청이 동시에 발생하여 상당히 좋은 성능을 확인할 수 있습니다. ab -n 100 -c 10 http://localhost:8000/_healthcheck

프로젝트 아키텍처

이 프로젝트는 DDD + CQRS 패턴에 따라 아키텍처가 구성되었으며, 여기에는 세 가지 주요 부분이 포함됩니다.

• 도메인(Domain) : 비즈니스 개념과 비즈니스 로직을 나타냅니다. 다른 부분에 대해서는 아무것도 몰라야 합니다.
• 응용 프로그램 : 작업을 정의하고 도메인 개체를 조정하여 문제를 해결합니다. Domain 에 대해서만 알 수 있습니다.
• 인프라 : Ui(컨트롤러) / 콘솔 / 타사 관련 문제를 담당합니다. 이를 통해 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)