Я про конкурентность и пишу. Пока в консоли запускаете:
Код: Выделить всё
UPDATE table SET amount = amount - 10 WHERE ...;Код: Выделить всё
SELECT * FROM table WHERE id = 5;
if ($product->amount ...) // 23
$product->amount = $model->amount - 20;
save($product);
UPDATE table SET amount = 3 WHERE id = 5Вот чтобы даже об интерфейсах, как-то не очень похоже на правду.
Про "корень компоновки" можно подробнее, а желательно на моем примере с модулем отзывов и модулем клиента. Все что Вы говорите очень похоже на ANTICORRUPTION LAYER (Адаптеры, фасады), но его использование оправдано когда есть две отдельные подсистемы (два разных контекста).anton_z писал(а): ↑2017.02.23, 16:16 Каждый модуль должен объявлять интерфейсы для зависимостей, реализации которых ему должен предоставить КОРЕНЬ КОМПОНОВКИ (приложение). В корне компоновки могут содержаться адаптеры, обеспечивающие реализацию того или иного интерфейса модуля с помощью классов другого модуля. Например, в модуле интернет-магазина (ecommerce) у вас объявлен интерфейс для оплаты с помощью платежного агрегатора PaymentAggregatorInterface. У вас есть модуль для платежей через Robokassa, Interkassa и т.д. В приложении можете создать реализацию интерфейса PaymentAggregatorInterface с помощью данных модулей. Также можно сделать модуль-связку: rk-ecommerce и положить реализацию туда. В свою очередь модуль платежной системы может требовать реализацию какого-то своего интерфейса для обработки событий прихода денег, проверки возможности оплаты и.т.п. Реализация последнего также может находиться в корне компоновки или модуле-связке.
В итоге получаете два полностью независимых друг от доуга модуля (ecommerce, rk) и корень комноновки, который знает как их связать.
Слоенная архитектура не предполагает, что слои низшего уровня знают о слоях высших уровней. Инфраструктура самый низший уровень.anton_z писал(а): ↑2017.02.23, 16:24Все могут знать о домене, в т.ч. инфраструктура. Не бывает независимой инфраструктуры. Она по природе своей пишется под конкретный домен. Домен не должен знать об инфраструктуре и других доменах. Он в центре системы.
Однако, инфраструктура не должна брать на себя функции домена и вызывать его поведение (передавать ему управление).
потому и знает об интерфейсе, поскольку вы его создали и расшарили, а надо было модель Author создать и адаптеры каких либо сущностей (Client / User) в сущность Author. Адаптеры не будут принадлежать ни первому ни второму модулю, но будут принадлежать модулю Application или Core (то, что anton_z называет корнем компоновки), который связывает остальные модули воедино.paurlift писал(а): ↑2017.02.24, 21:37Вот чтобы даже об интерфейсах, как-то не очень похоже на правду.
У меня при создании комментария на вход приходит AuthorInterface, его реализует клиент или еще кто-то, кто может быть автором чего-либо на сайте, т.е. уже получается модуль отзывов знает о интерфейсах других модулей.
у нас и есть независимые модули, независимые контексты, которые где-то надо привести к одному контексту - контексту приложения.paurlift писал(а): ↑2017.02.24, 21:37Про "корень компоновки" можно подробнее, а желательно на моем примере с модулем отзывов и модулем клиента. Все что Вы говорите очень похоже на ANTICORRUPTION LAYER (Адаптеры, фасады), но его использование оправдано когда есть две отдельные подсистемы (два разных контекста).
это не совсем так. инфраструктура - это собственно реализация доменных сервисов/репозиториев, а реализация не может не знать о том, что реализует.
Если один, то как бы его Вы назвали и где бы Вы создавали отзыв? Отзыв могут оставлять не только клиенты. Да и клиенты еще могут писать на сайт посты на форум, создавать заявку в службу поддержки и т.д. (это я к тому, что так можно все действия связанные с клиентом свалить в один модуль, вместо того чтобы провести между модулями разумную грань в виде однонаправленной связности)
AuthorInterface - реализуют разные сущности и нужен он не только для review.
Не находите в этом нарушения слоенной архитектуры? Если то что мапер знает namespace модели, можно еще как-то отнести к исключению, то вот как Вы относитесь к явному созданию VO при сборке агрегата ($client->phoneNumbers[] = new PhoneNumber($phoneNumber);) ?
Я говорю здесь про репозиторий у которого нет домена. В application сервисе вызываю метод репозитория, который сохранит данные для аналитики. В этом случае где должен лежать интерфейс репозитория?
Я не понял, я правильно сформулировал причину? Пример, у меня есть инфраструктурный сервис отправляющий уведомления клиентам всеми доступными способами(email, sms). 90% случаев использования этого сервиса:
Код: Выделить всё
namespace application/payment;
use domain/contracts/infrastructure/NotificationServiceInterface;
class PaymentService
{
public function __construct(NotificationServiceInterface $notificationService)
{
$this->notificationService = $notificationService;
}
public function execute()
{
// Оплата
$this->notificationService->notify('success_buy', $client);
}
}
zelenin писал(а): ↑2017.02.24, 21:52потому и знает об интерфейсе, поскольку вы его создали и расшарили, а надо было модель Author создать и адаптеры каких либо сущностей (Client / User) в сущность Author. Адаптеры не будут принадлежать ни первому ни второму модулю, но будут принадлежать модулю Application или Core (то, что anton_z называет корнем компоновки), который связывает остальные модули воедино.paurlift писал(а): ↑2017.02.24, 21:37Вот чтобы даже об интерфейсах, как-то не очень похоже на правду.
У меня при создании комментария на вход приходит AuthorInterface, его реализует клиент или еще кто-то, кто может быть автором чего-либо на сайте, т.е. уже получается модуль отзывов знает о интерфейсах других модулей.
у нас и есть независимые модули, независимые контексты, которые где-то надо привести к одному контексту - контексту приложения.paurlift писал(а): ↑2017.02.24, 21:37Про "корень компоновки" можно подробнее, а желательно на моем примере с модулем отзывов и модулем клиента. Все что Вы говорите очень похоже на ANTICORRUPTION LAYER (Адаптеры, фасады), но его использование оправдано когда есть две отдельные подсистемы (два разных контекста).
Реализация доменных сервисов - это инфраструктура? Можете пример какой-нибудь привести? Реализация репозитория - да, это инфраструктура. Ну вот когда реализация репозитория, которая в инфраструктуре находится, начинает много чего знать о домене, мне кажется, это прямое нарушение слоев. Допускаю, как исключение, что репозиторий будет знать о namespace модели + знать о названиях её свойств, которые ему нужно заполнить. А желательно это вынести в какой-то конфиг файл. (как в Doctrine). В Yii я делаю это в container.
он намекает, что у вас этот модуль протек во все остальные - не независим.paurlift писал(а): ↑2017.02.24, 22:26Если один, то как бы его Вы назвали и где бы Вы создавали отзыв? Отзыв могут оставлять не только клиенты. Да и клиенты еще могут писать на сайт посты на форум, создавать заявку в службу поддержки и т.д. (это я к тому, что так можно все действия связанные с клиентом свалить в один модуль, вместо того чтобы провести между модулями разумную грань в виде однонаправленной связности)
В моем случае - это точно 2 разных модуля.
маппер - это то, что маппит непосредственно результат выборки из хранилища к конкретной сущности. то есть маппер не может не знать о об этой сущности (другое дело, что сам маппинг может быть описан в конфигах или в фабрике, но это детали реализации)
там же в application
инфраструктура - это инфраструктура не приложения, а доменного слоя. то есть сервис приложения должен находиться в слое приложения (и интерфейс и реализация). Если понадобятся уведомления в доменном слое, тогда создадите новый интерфейс в домене и реализуете его в инфра.paurlift писал(а): ↑2017.02.24, 22:26Я не понял, я правильно сформулировал причину? Пример, у меня есть инфраструктурный сервис отправляющий уведомления клиентам всеми доступными способами(email, sms). 90% случаев использования этого сервиса:Т.е. почти всегда это операционный уровень, и разумно было положить интерфейс NotificationServiceInterface куда-то на уровень application, у домена нет к нему никакой привязки. Но, завтра мне нужно его использовать в доменном сервисе, а интерфейс то уже лежит в application. Мне придется переносить интерфейс на доменный уровень.Код: Выделить всё
namespace application/payment; use domain/contracts/infrastructure/NotificationServiceInterface; class PaymentService { public function __construct(NotificationServiceInterface $notificationService) { $this->notificationService = $notificationService; } public function execute() { // Оплата $this->notificationService->notify('success_buy', $client); } }
именно
не понимаю, какие примеры надо? тут все как везде. интерфейс, реализация
это инфраструктура - воспринимайте это слово не как термин DDD, а в общем смысле - обслуживание определенной области чего-либо. Инфраструктура района, инфраструктура гостиницы, инфраструктура города. Инфраструктура может знать о домене, т.к. она домен непосредственно обслуживает. Она не может и не должна обслуживать другой слой через адаптеры, т.к. это не имеет смысла. Инфраструктура существует для конкретного домена. Естественно надо ограничить знания, чтобы не размазывать его по многим местам, например сущности создавать через доменные фабрики, но это не вопрос слоев, а вопрос чистой архитектуры и разделения ответственностей.
Отзывы к товарам магазина у меня в модуле "Магазин". Отзывы к фирмам - в модуле "Каталог организаций". А "отзывы" или "категории" - это не совсем модули.
Это называют ограниченными контекстами. Обычно взаимодействующими через доменные события. При этом и однонаправленные связи между ними оказываются не нужны: http://www.elisdn.ru/blog/86/module-relations-on-yii2paurlift писал(а): ↑2017.02.24, 22:26 Отзыв могут оставлять не только клиенты. Да и клиенты еще могут писать на сайт посты на форум, создавать заявку в службу поддержки и т.д. (это я к тому, что так можно все действия связанные с клиентом свалить в один модуль, вместо того чтобы провести между модулями разумную грань в виде однонаправленной связности)
Не нормальная. Нормальная - это когда между модулями есть трансформер, преобразующий объекты одного модуля к интерфейсам другого:
Код: Выделить всё
[ модуль 1: интерфейс 1 ] <- конвертер -> [ модуль 2: интерфейс 2 ]Репозиторию нужно их как-то создавать. Если не получается явно из-за хитрого конструктора, то создавайте через рефлексию как сущности. Инфраструктура - это не самостоятельный слой.
Создайте папку analytics. Но я аналитику через события собираю.
Поставите курсор на имя интерфейса в PhpStorm, нажмёте F6, поменяете namespace и нажмёте Enter.
Пример доменного сервиса - CreateOrderFromCart. Он создает объект заказа(Entity) из корзины (VO). Вот я никак не могу представить, чтобы реализация находилась на инфраструктурном уровне. Т.е. инфраструктура должна создавать domain объекты. Не получается к инфраструктуре относится, как не к слою в разрезе слоенной архитектуры (DDD тут даже не при чем, но слоенная архитектура, часто используемый архитектурный патерн совместно с DDD)zelenin писал(а): ↑2017.02.24, 22:58именно
собственно название само за себя говорит. вы создаете рабочую инфраструктуру для работы доменного слоя.
не понимаю, какие примеры надо? тут все как везде. интерфейс, реализация
это инфраструктура - воспринимайте это слово не как термин DDD, а в общем смысле - обслуживание определенной области чего-либо. Инфраструктура района, инфраструктура гостиницы, инфраструктура города. Инфраструктура может знать о домене, т.к. она домен непосредственно обслуживает. Она не может и не должна обслуживать другой слой через адаптеры, т.к. это не имеет смысла. Инфраструктура существует для конкретного домена. Естественно надо ограничить знания, чтобы не размазывать его по многим местам, например сущности создавать через доменные фабрики, но это не вопрос слоев, а вопрос чистой архитектуры и разделения ответственностей.
из описания следует, что это сервис без зависимостей, т.е. может быть реализован в рамках домена.
Domain\Service\CreateOrderFromCart - самодостаточный доменный сервис. Делаем классом. Но ему (или соседнему сервису регистрации пользователя) может понадобиться хешер паролей Domain\Service\PasswordHasher, если нужно автоматом создать пользователя при быстром заказе.
Код: Выделить всё
namespase Domain\Service;
use Domain\Entity\User\Password;
use Domain\Entity\User\Hash;
interface PasswordHasher
{
function hash(Password $password): Hash;
function validate(Password $password, Hash $hash): bool;
}Код: Выделить всё
namespase Infrastructure\Service;
use Domain\Service\PasswordHasher;
use Domain\Entity\User\Password;
use Domain\Entity\User\Hash;
class YiiPasswordHasher implements PasswordHasher;
{
function hash(Password $password): Hash
{
return new Hash(Yii::$app->security->generatePasswordHash($password->getValue()));
}
...
}В итоге получается что-то такое, если я правильно понял:zelenin писал(а): ↑2017.02.24, 21:52потому и знает об интерфейсе, поскольку вы его создали и расшарили, а надо было модель Author создать и адаптеры каких либо сущностей (Client / User) в сущность Author. Адаптеры не будут принадлежать ни первому ни второму модулю, но будут принадлежать модулю Application или Core (то, что anton_z называет корнем компоновки), который связывает остальные модули воедино.paurlift писал(а): ↑2017.02.24, 21:37Вот чтобы даже об интерфейсах, как-то не очень похоже на правду.
У меня при создании комментария на вход приходит AuthorInterface, его реализует клиент или еще кто-то, кто может быть автором чего-либо на сайте, т.е. уже получается модуль отзывов знает о интерфейсах других модулей.
Код: Выделить всё
namespace application\reviews;
use domain\base\TransactionManagerInterface;
use domain\client\ClientRepositoryInterface;
use domain\client\ManageReviewInterface;
use domain\reviews\ReviewRepositoryInterface;
class CreateReviewService extends ApplicationService
{
public function __construct(
ClientRepositoryInterface $clientRepository,
TransactionManagerInterface $transactionManager,
ReviewRepositoryInterface $reviewRepository,
ManageReviewInterface $clientAuthor
){
$this->transactionManager = $transactionManager;
$this->clientRepository = $clientRepository;
$this->reviewRepository = $reviewRepository;
$this->clientAuthor = $clientAuthor;
}
public function execute($paceId, $reviewDto)
{
$client = $this->clientRepository->findById($this->currentClient->id);
$this->clientAuthor->setClient($client);
$this->transactionManager->beginTransaction();
try {
$reviewId = $this->reviewRepository->nextIdentity();
$review = $this->clientAuthor->createReview($reviewId, $paceId, $reviewDto);
$this->reviewRepository->save($review);
$this->transactionManager->commit();
} catch (\Exception $e){
$this->transactionManager->rollback();
}
}
}
--------------------
namespace anticoruption\clientReviews;
use domain\client\Client;
use domain\client\ManageReviewInterface;
use domain\reviews\AuthorInterface;
use domain\reviews\Review;
use domain\reviews\ReviewDto;
class ClientAuthor implements ManageReviewInterface, AuthorInterface
{
private $client;
public function setClient(Client $client)
{
$this->client = $client;
}
public function createReview($reviewId, $paceId, ReviewDto $reviewDto)
{
return new Review($reviewId, $paceId, $reviewDto, $this);
}
public function getAuthorFullName()
{
return $this->client->name . ' ' . $this->client->surname;
}
}
-----------------------
namespace domain\reviews;
interface AuthorInterface
{
public function getAuthorFullName();
}
-----------------------
namespace domain\client;
use domain\reviews\ReviewDto;
interface ManageReviewInterface
{
public function createReview($reviewId, $placeId, ReviewDto $reviewDto);
}
Вы интерфейсы инфраструктурных сервисов располагаете в папке Domain/Service ?ElisDN писал(а): ↑2017.02.26, 11:31который работает с VO домена.Код: Выделить всё
namespase Domain\Service; use Domain\Entity\User\Password; use Domain\Entity\User\Hash; interface PasswordHasher { function hash(Password $password): Hash; function validate(Password $password, Hash $hash): bool; }
А реализацию уже делаем в инфраструктуре:
и настраиваем в контейнере его привязку к интерфейсу.Код: Выделить всё
namespase Infrastructure\Service; use Domain\Service\PasswordHasher; use Domain\Entity\User\Password; use Domain\Entity\User\Hash; class YiiPasswordHasher implements PasswordHasher; { function hash(Password $password): Hash { return new Hash(Yii::$app->security->generatePasswordHash($password->getValue())); } ... }
В итоге контроллер дёргает сервис приложения, он дёргает доменные сервисы, доменные репозитории и управляет доменными сущностями и VO. Но при этом ни контроллер, ни приложение, ни домен не догадываются, что есть какая-то там инфраструктура и что половина сервисов подменены интерфейсами и реализованы в ней. Единственное упоминание инфраструктурных классов имеется только в настройках контейнера. В итоге "инфраструктура" здесь - это полностью невидимый слой-адаптер, реализующий взаимодействие с внутренностями фреймворка.
Пожалуйста, конкретнее и как бы Вы сделали? Что-то может быть упустил, писал "на коленке".
Нужны, нет у меня модели Author как таковой, а есть интерфейс AuthorInterface. А его уже должны реализовывать AuthorClientTransformer, AuthorPartnerTransformer, AuthorManagerTransformer. А в конструктор отзыва должен всегда приходить AuthorInterface.
Вы AuthorClientTransformer отнесли к операционному уровню? Я думаю, для адаптеров и фасадов хорошо выделять свой уровень (предохранительный)
Я в самом первом посте об этом спросил, ElisDN ответил, что использовать его можно везде, это просто удобная замена массивам и я с ним согласен.
А VO можно передавать? Я передаю AuthorInterface, а не сущность.
Вот и советуем сделать отдельную сущность review\Author вместо интерфейса AuthorInterface. Это если очень хочется сделать review именно отдельной системой.
По определению DTO это объект передачи данных. Передачи между слоями или сервисами. Идеально подходит как замена ассоциативному массиву для передачи больших наборов полей. Например, из контроллера в сервис приложения или из сервиса приложения в сервис домена. А в сущности их передавать особо не имеет смысла, так как вместо них там уже есть удобные VO.
Раскладываю по смыслу:
Код: Выделить всё
Domain/
Service/
Geo/
Coder.php
Address.php
Coordinate.php
PasswordHasher.phpМне хотелось узнать как подружить 2 модуля в первую очередь и Ваши советы очень помогли, спасибо всем кто отвечал.