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 。
• 基础设施：负责 Ui（控制器）/控制台/第 3 方问题。这样就可以了解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)