Меню
Что нового?

Laravel Выбор Framework

ясно. чукча не читатель, чукча писатель, да еще и слепой

вызов автоинкремента делает $userRepository->create недетерминированным,
пол-темы обсуждается что "дергать" автоинкрементный генератор ID не надо
 
Последнее редактирование:
со всякими CQRS это и так понятно почему. Человеку сложно понять зачем CQRS.

Я вот кстати чутьем чую, что вы правы. Получить Id - это даже по принципу Single Responsibility должна быть отдельная операция. Но проектов у меня таких не было. Поэтому с моей точки зрения - вас сложно понять. Поэтому типа "не обьяснили".
 
а нельзя эту интересную тему подчистить от нечитателей? :)
 
hell0w0rd написал(а):
PHP: 
try {
  $user = $userRepository->create($req->getBody());
  $user->addPhone(...);
  $trx->commit();
  $res->redirect('profile', ['id' => $user->getId()]);
} catch (\Exception $e) {
  $trx->rollback();
  throw $e;
}
Что в этом коде недетерминированного, или неявного?
Нажмите для раскрытия...

Смешиваются инфраструктурный слой(знание о реализации репозитория), domain слой(добавление телефона), и презентационный слой - редирект.
Данный код связывает вместе в кашу три разные слоя.
Для скорости разработки это большой плюс.
Минус для сохранения целостности domain слоя, так как логика domain слоя раскидана по многим actionам контроллеров(что является презентационным слоем).

Вся суть в том, чтобы сделать domain слой абсолютно голым(только простейшие php функции).
Я осознал кстати это тогда, когда покрыл domain слой unit тестами, моков было ОЧЕНЬ мало.
 
Последнее редактирование:
@grigori , @Вурдалак вы чот ребята перемудряете
http://martinfowler.com/bliki/CQRS.html

In particular CQRS should only be used on specific portions of a system (a Bounded Context in DDD lingo) and not the system as a whole. In this way of thinking, each Bounded Context needs its own decisions on how it should be modeled.
Нажмите для раскрытия...

строить отношения товар-корзина, через cqrs глупо, ибо это один контекст и один домен

UPD. то есть пользоваться обычным CRUD для корзины, заказа и.т.п. норм вполне, а вот отдавать данные по заказам домену аналитики как раз через cqrs
 
Redjik написал(а):
строить отношения товар-корзина, через cqrs глупо, ибо это один контекст и один домен
Нажмите для раскрытия...
Фаулер утверждает следующее: CQRS — это сложно, применять нужно только в определённых контекстах. Ты говоришь: товар-корзина в одном контексте, поэтому CQRS тут применять глупо. Логика?
 
@Redjik, у меня ощущение, что ты не прочел ни тему, ни статью, на которую ссылаешься. Фаулер говорит ровно противоположное:

CQRS нужно применять на специфических участках системы (в связанном контексте).
Каждый связанный контекст требует индивидуального решения как его смоделировать.

Утверждение
cqrs глупо, ибо это один контекст и один домен
Нажмите для раскрытия...
противоречит словам Фаулера полностью.

Он предостерегает от overengineering, и напоминает, что mainstream - это CRUD, а разделять нужно на сложных участках.
The mainstream ... is a CRUD datastore.
As our needs become more sophisticated we steadily move away from that model.
... in more complicated domains, having the same conceptual model for commands and queries leads to a more complex model that does neither well.
Нажмите для раскрытия...

Я в свою очередь начал с вопроса про список проблем, которые возникают, для определения сферы применимости. Если этих проблем нет - тебе это не нужно.
 
Последнее редактирование:
А можно глупый вопрос? На обычную корзину скажем из 3х таблиц, сколько моделей вы имеете? Меня не интересует функциональность и ответ типа в зависимости от... Больше среднее статистическое
 
Кстати часто, где применяется CQRS дальше следуют слова Event Sourcing.
В принципе для того же Billing Account - это ведь круто, все движения средств = следующие друг за другом события.
Но где можно увидеть код подобного на php? Это вообще реально? Ведь это порождает море проблем: 1 бд для чтения, 1 для изменений, синхронизация между ними, снапшоты, чтобы с нуля не читать весь агрегат, взаимодействие между агрегатами, etc.
 
Чтото путаешь, не? Одно дело накидать кучу запросов, другое на событие "покупка" приоритетно выступают обработчики, третье разделенная база, а тут вроде о избежании тормоза, изменением подхода, способом типа, "неожидание ответа на запись"
 
Последнее редактирование:
Ладно, на пальцах,

Пример номер раз:
пользователь ткнул добавит товар в корзину, отправился запрос, пришел ответ с сервера 204, js добавил товар в плашку с корзиной, нафига тут id?

Пример номер два:
кровь из носа нужно вернуть на клиент id?
ок, команда создает корзину и заказ, эвент обновляет вид через observer... ну или просто тупо оповещает тех, кого нужно оповестить (и да ... это не для веб приложения, это классическое десктопное mvc)

Пример номер три:
кровь из носа нужно вернуть на клиент id, да еще и в вебе?
ну так и делайте блин через контроллер, команда отработала, эвент запустился, контроллер вернул результат

https://github.com/qandidate-labs/b...xamples/command-handling/command-handling.php
намекну, то, что внизу, должно быть в контроллере ;)

Блин я же уже скидывал ссылку на бродвеев пару раз, или нет?
 
@Adelf, на лог намекаешь? я храню логом и движение средств и товаров, и на trigger after insert into лог считаю в кеш, но id записи все одно ожидаю.
 
Последнее редактирование:
Redjik написал(а):
пользователь ткнул добавит товар в корзину, отправился запрос, пришел ответ с сервера 204, js добавил товар в плашку с корзиной, нафига тут id?
Нажмите для раскрытия...
Добавление товара в корзину — это не создание новой сущности. О каком id идёт речь?

Redjik написал(а):
https://github.com/qandidate-labs/b...xamples/command-handling/command-handling.php
намекну, то, что внизу, должно быть в контроллере ;)
Нажмите для раскрытия...
Да видали уже такой подход, и я солидарен вот с этим чуваком: https://groups.google.com/forum/#!s...0controller/dddinphp/PoUdMKdqMuE/ZYZlpyrdwa4J
Во-первых, тупо выглядит хаком. $this->redirect() выбрасывает исключение шо ле?
Во-вторых, я не вижу ни одного кейса, вот кроме как с созданием новой сущности. Ради этого давать знать presentation о domain events? Мне эта идея не нравится.

И я не понял: это ты это «на пальцах» объяснял, что нафиг не нужно генерировать id до команды? AUTO_INCREMENT рулит? Серьезно?
PHP: 
final class User
{
    public function register($id, UserName $name, Email $email, ...)
    {
        $user = new self(...);
        $user->record(new UserHasRegisteredEvent($this->id));
        $user->onModeration();

        return $user;
    }

    private function onModeration()
    {
        $this->status = Status::onModeration();
        $this->record(new UserHasBeenSentOnModerationEvent($this->id));
    }
}
Покажи аналог без $id, c AUTO_INCREMENT.
 
Последнее редактирование:
Я почему не понял: сначала @Redjik говорит, что CQRS тут не нужен:
Redjik написал(а):
строить отношения товар-корзина, через cqrs глупо
Нажмите для раскрытия...

Следующее его сообщение содержит информацию о том, как жить с CQRS без предварительной генерации id:
Redjik написал(а):
Ладно, на пальцах,
<...>
кровь из носа нужно вернуть на клиент id, да еще и в вебе?
ну так и делайте блин через контроллер, команда отработала, эвент запустился, контроллер вернул результат
Нажмите для раскрытия...

Я запутался, @Redjik. Какой подход ты пытаешься защитить, что пытаешься донести?
 
Вурдалак написал(а):
Я почему не понял: сначала @Redjik
Я запутался, @Redjik. Какой подход ты пытаешься защитить, что пытаешься донести?
Нажмите для раскрытия...

Никакой =) Я болею, не могу мысли нормально выразить =(((

И я не понял: это ты это «на пальцах» объяснял, что нафиг не нужно генерировать id до команды? AUTO_INCREMENT рулит? Серьезно?
Нажмите для раскрытия...
Я нигде такого не говорил, мне нравится подход с генерацией uuid на клиенте, возможно, даже больше.

Покажи аналог без $id, c AUTO_INCREMENT.
Нажмите для раскрытия...
так вон Матиаз показывает в той же ссылке (у него кстати классный доклад есть про CRUD головного мозга, найти?)
 
Войдите или зарегистрируйтесь для ответа.
Сверху