Download the PHP package antonyan/ddd-mappers-project without Composer

DDD project

This project is intended to help developers in the implementation of DDD approach with PHP programming language. There is a lot of theoretical information and a few examples.

DDD-mappers-project has all that yo u need to create a commercial product in the short term and high quality (high level of maintainability means)

Overview

Our team doesn't want to emphasize technical things that's why we're using well-known solutions like Symfony components where it's possible.

Besides, we've created a lot of different useful features that can significantly accelerate the development.

Quick start

All that you need is to run a command Setup DB See Db interaction -> connection

Request

To validate request data we created annotations that you can specify in presentation service (controller). Presentation services are usually based in

Example:

In this case, our validator checks all specified fields and remove any additional from a request.

Available validation types:

Routing

Config for request you can find by path The project uses under the hood but we did several improvements that make easy to add a route.

If you need to create a route for a specific case you can use addGET, addPOST, addDELETE or addPUT. In case if you are creating data-centric module you can use addCRUD and project creates all urls with mapping to the presentation service (controller).

`

Context

The main idea of this project to allow a developer to create architecture which will consist of contexts and modules. Easiest way to create context is generate it with command. It'll be created in and consists of config, Services folders and Contract.

config

Folder consists of two files config.php and container.php In config.php you can specify all data that can be changed but should be available in Service (e.x. time to live for token, number of attempts etc.)

Container is used to specify dependencies (Dependency Injection). In this file you should register all module services.

Example:

Services

In this folder, you can see context service which orchestrates interactions with all services from module level. It can be simple method call

or it can receive some information from one service and send it to another.

Contract

It's a context contract and services outside context can use it only for interaction with a module.

Example: To use UserService you should specify in presentation service (controller)

Module

If you want to create a Module in a quick way you should create Model in the root of the context

Example:

And generate module . You should specify namespace of the created model.

In context will be created Module (in example SomeModelModule) which will consist such folders:

config

This folder almost the same as in the case of Context, but config consists DB mapping for Model

Example:

SomeModelDbTranslator is metadata class for SomeModel.

• table - it's a table name from db
• columns - mapping between class Model properties and database fields
• create - there you should specify a name of the identifier of the Model
• update - there you should specify a name of the identifier(s) of the Model for update

For the general case (if you need CRUD only), all data for Module will be generated automatically and you shouldn't care about anything.

But you can rewrite or create you own solutions in other cases.

Factories

There you can see simple factory which creates Model

Mappers

There you can see mapper for Model. Was created for typization only.

Services

It's stateless classes for business logic implementation. In case of simple data-centric application can seems like proxy from Mapper to ContextService.

Main idea

Beside fast domain design implementation, this project has an idea of strict dependencies separation. Each service has its own container which placed in the config folder in the same Module if it's module service or in the context if it's context service.

On top of that, to have access to the infrastructure classes (HttpClient, MySqlClient) BaseService automatically merge it into the each service's container.

Our recommended approach is to follow the next rules:

• presentation service can use context service only;
• context service can use module services from own context or other context services;
• module service can use mappers, factories and models from own module only.

Infrastructure Container

In you can attach own listeners or subscribers to events and override specific reserved services.

Customize error handling

To customize error handling, which triggered by exception listener, you can override service which is reserved.

Infrastructure events

• thrown before executing request. As const name

Symfony kernel events

KernelEvents::EXCEPTION
...

Event listeners and subscribers

To attach subscriber or listener:

Application registry

Application registry is a global container and developed as singleton and registry pattern. Can be accessed from services which extends BaseService.