Laravel Выбор Framework

[grigori]

@Вурдалак, ага, согласен, это просто чтоб народ когда будет читать не воспринимали это как библию с проповедями, а конкретно

 

[Вурдалак]

nextval() в Postgres - точно такое же нарушение CQS, как и любая increment-and-return функция - в memcached, shared memory, etc

Ты рассматриваешь нарушение этого принципа на уровне метода nextval(). Но на это нарушение всем пофиг. Мы же сейчас говорим про нарушение на уровне сервисов. Здесь это гораздо принципиальнее.

 

[grigori]

да, с этим тоже согласен

значит, проблема сводится к такой проектировке системы, чтобы сущности, которые генерируют autoincrement id при создании, были созданы до зависимых сущностей

условно, запись для товара должна быть создана до генерации сущностей свойств этого товара

 

[Вурдалак]

А если вернуться как раз к такому типичнейшему действию как регистрация.
1) Пользователь ввел login, email, password.
2) Команду можем делать только синхронной, пользователю нужен ответ.
3) Отправляем сервису login, email, password - получаем id...
У нас уже не CQRS.

Причем тут CQRS и асинхронность? id ты можешь получить из какого-то специального сервиса перед выполнением команды регистрации.

На клиенте генерировать ID это уже имхо дико.

А что тут дикого?

 

[Sufir]

значит, проблема сводится к такой проектировке системы, чтобы сущности, которые генерируют autoincrement id при создании, были созданы до зависимых сущностей

условно, запись для товара должна быть создана до генерации сущностей свойств этого товара

Вот тут не понял, а каким образом, при любом подходе, можно создать зависимую сущность, пока не существует той сущности от которой она зависит?

 

[Redjik]

Меня смущает, что на практике скорее всего придётся использовать и числовой (для FK, для производительности, для human readablity, etc.) и UUID одновременно.

для restful микросервисов оказалось самое оно, уже 10ок сущностей и все ключи uuid, полет нормальный

 

[grigori]

с индексами для UUID проблем особо нет - в mysql есть decimal/char, или можно разложить на разные поля
https://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/

 

[grigori]

Вот тут не понял, а каким образом, при любом подходе, можно создать зависимую сущность, пока не существует той сущности от которой она зависит?

Речь про объекты в процессе исполнения. Например, пришел запрос на создание заказа товара, идет его валидация и обработка

$Order = new Order();
$Basket = new Basket($_REQUEST['basket']);
if ($Basket->isValid()){
    $Order->save();
    $Basket->setOrderId($Order->getId());
    $Basket->save();
}

если вдуматься, последовательность действий нелогичная, хочется так:

$Order = new Order($id);
$Order->addProductsToBasket($_Request);
$Order->save();
echo $Order->resultStatus();

про этот $id, который надо откуда-то брать, и весь разговор

 

[stalxed]

Причем тут CQRS и асинхронность? id ты можешь получить из какого-то специального сервиса перед выполнением команды регистрации.


А что тут дикого?

Хм, интересно:

try {
    $idGen = new \Infrastructure\IdGenerator();
    $id = $idGen->generate();

    $service = new \Application\CreateUserService();
    $service->create(new \Application\CreateUserCommand($id, $_POST['username'], $_POST['password'], $_POST['email']));

    header('Location: http://domain.com/user/profile/'. $id);
} catch (\Exception $e) {
    http_response_code(500);
}

Да, в принципе, жить можно....

 

[hell0w0rd]

оО а чем вы оправдываете такую жесть, против вот этого:

$user = $userRepository->create($req->getBody());
$res->redirect('profile', ['id' => $user->getId()]);

 

[Вурдалак]

оО а чем вы оправдываете такую жесть, против вот этого:

$user = $userRepository->create($req->getBody());
$res->redirect('profile', ['id' => $user->getId()]);

Прочти тему?

 

[grigori]

@hell0w0rd, добавь в свой код создание пары сущностей типа UserPhones и отказ от создания пользователя если телефоны не прошли валидацию

 

[hell0w0rd]

@hell0w0rd, добавь в свой код создание пары сущностей типа UserPhones и отказ от создания пользователя если телефоны не прошли валидацию

Ну, у нас же реляционная база? Транзакции

 

[Вурдалак]

Понять преимущества с позиции вот такого кода:

$user = $userRepository->create($req->getBody());
$res->redirect('profile', ['id' => $user->getId()]);

невозможно. Типичный CRUD-подход.

Если ты будешь двигаться в сторону rich model, где у тебя будут события записываться внутри сущности, одним из которых может быть событие а-ля UserHasSignedUp, которое записывается где-то в конструкторе и требует $id; в сторону rich model, где у тебя будут именованные конструкторы (статические методы) с проверкой бизнес-требований внутри; если ты поймёшь, что писать бизнес-логику в web-контроллерах приведёт к проблемам реюзабельности кода и потребуется service layer; если ты поймёшь, что service layer в виде «обычных» сервисов не очень удобен и лучше сделать разделение на command/query (CQRS) и появится command bus, который ничего не возвращает, а значит и не может возвращать $id. Вот где-то после осознания необходимости и удобства этих штук придёт понимание, что всё становится проще, если $id есть заранее.

А так — разговор глухих со слепыми.

 

[grigori]

Транзакции

а теперь осознай что тразакции тебе нужны только для того чтобы добраться для генератора уникальных ID,
следовательно, твой код можно переписать как

try {
$idGen = new \Infrastructure\IdGenerator();
$id = $idGen->generate();

только во втором случае действия описаны явно, а откат транзакции - неявные операции, что намного хуже

 

[hell0w0rd]

только во втором случае действия описаны явно, а откат транзакции - неявные операции, что намного хуже

Почему неявные? У СУБД, на сколько я знаю, написан механизм, если свет моргнул во время транзакции, как-то с ней разобраться. А что будет если твой такой код упадет?
Конечно его тоже можно завернуть в транзакцию, наверное так и делают. И тогда возвращаемся к моему первому вопросу.

 

[hell0w0rd]

...проблемам реюзабельности кода...

Ну то есть все к реюзабельному коду сводится? Мне реюзабельность понадобилась пару раз, и о ней обычно, если не известно, то можно догадаться заранее. А если потом понадобилось - то можно и порефакторить.

 

[Вурдалак]

Ну то есть все к реюзабельному коду сводится?

Нет, всё сводится к точному понимаю бизнес-требований и отсутствию двойного толкования. Ты сейчас хочешь поговорить на тему «а зачем нужен DDD, мне и так хорошо»?

 

[grigori]

@hell0w0rd, я открыт к спору, а для обучения значениям базовых терминов есть учебники и статьи.
компенсировать нехватку базовых знаний можно по википедии: детерминированный алгоритм и побочный эффект

@Вурдалак, забей, он не понимает значений слов, которые ты пишешь

 

[hell0w0rd]

@grigori, не понимаю к чему эти термины тут.

try {
  $user = $userRepository->create($req->getBody());
  $user->addPhone(...);
  $trx->commit();
  $res->redirect('profile', ['id' => $user->getId()]);
} catch (\Exception $e) {
  $trx->rollback();
  throw $e;
}

Что в этом коде недетерминированного, или неявного? У нас либо будет пользователь с телефоном, либо не будет. Да, в случае ошибки мы заденем генератор id напрасно, но вы его и так дергаете.