Exceptions

[ksnk]

Поэтому можно ему дать сменить пароль без ввода старого, верно?

Нет. Он отошел попить кофе и его коллега. с соседнего стола, или хаккер с системой уделенного управления, собирается стырить его аккаунт.

 

[Adelf]

Нет. При попытке смены пароля аутентификация пользователя выполняется принудительно.

не выполняется никакая аутентификация. Юзер аутентифицирован.

Я придумал две слабые причины того, что это не вопрос авторизации и аутентификации.
Можно представить, что админам разрешено менять пароли юзеров, но только если они знают его старый пароль. Звучит глупо, но по крайней мере не невозможно. Таким образом это никакая не аутентификация .
А еще можно представить что в сущности юзер лежит некий секретный токен и зашифрован он паролем!!!
Т.е. при смене пароля надо его расшифровать старым паролем и зашифровать новым паролем. Поэтому старый пароль - это вполне себе атрибут этого действия. И если он не соответствует, то расшифровать не получится.

 

[Adelf]

Но сейчас придет @grigori и начнет прибаутками смеяться над моими жалкими попытками объяснить своё мнение

 

[Adelf]

Даже банально текст ошибки будет разный. "Старый пароль неверный", а не "Неверный логин или пароль".
Но это третья слабая причина

 

[AnrDaemon]

Да плевать, что юзер аутентифицирован! С десятого этажа плевать!
Просто вручную вызывается команда проверки пароля, так словно он в первый раз зашёл.

 

[Вурдалак]

PostWasSentForPreModeration - это статус, свойство сущности.
...
Аналогично, ответ на запрос по изменению поста не должен содержать статус этого поста.

Во-первых, это событие.
Во-вторых, я имею полное право в ответ на команду выдавать список событий.

Я бросил кости — я хочу узнать результат бросания костей, куда двинулась моя фигурка на игровом поле и к чему это привело.

У тебя искажённое представление об CQRS. CQRS ничего не говорит о методах и что они возвращают, там речь лишь про разделение write и read models.

 

[grigori]

не выполняется никакая аутентификация. Юзер аутентифицирован.

задал мне вопрос - и сам себе ответил

Но сейчас придет @grigori и начнет прибаутками смеяться над моими жалкими попытками объяснить своё мнение

тихо сам с собою

серьезно, давай общаться чуть более связанно

 

[grigori]

Аутентификация - это проверка не пароля, а пользователя.
Способов узнать пользователя много, я сейчас переписываю сайт на отсутствие паролей вообще.

Давайте не обсуждать "Нужна ли аутентификация по паролю при смене пароля" для абстрактной системы в вакууме. Вариантов чуть более, чем дохрена - от множества 2fa, таких как СМС, usb-ключа, сканера отпечатка пальца в яндекс-деньгах, до личного посещения мной филиала банка с паспортом. Грубо говоря, если вы не пишите ничего сложнее интернет-магазина - это не значит, что аутентификация - это проверка пароля.

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

 

[grigori]

Во-первых, это событие.
Во-вторых, я имею полное право в ответ на команду выдавать список событий.

Я бросил кости — я хочу узнать результат бросания костей, куда двинулась моя фигурка на игровом поле и к чему это привело.

согласен, что это событие, надо это обдумать

CQRS ничего не говорит о методах и что они возвращают, там речь лишь про разделение write и read models.

cqrs - это про контракты в программировании, не про модели

 

[grigori]

@Вурдалак, тут мы возвращаемся к различию событийной архитектуры и REST, который, в соответствии с названием, оперирует состояниями. Согласен, событийная модель нужна и полезна. Буду думать дальше.

 

[Вурдалак]

cqrs - это про контракты в программировании, не про модели

https://martinfowler.com/bliki/CQRS.html

At its heart is the notion that you can use a different model to update information than the model you use to read information.
...
The change that CQRS introduces is to split that conceptual model into separate models for update and display, which it refers to as Command and Query respectively following the vocabulary of CommandQuerySeparation.

Вероятно, ты путаешь с CQS. CQS относится к CQRS примерно как диверсификация рисков в экономике к, допустим, поговорке «не клади все яйца в одну корзину». Идея одна, но семантические уровни разные: в одном речь про методы, а в другом — как раз про модели.

Существует распространённое заблуждение про то, что command bus — это «fire and forget», что commands «one way only». Это не так. Команды как раз по своей природе синхронны, мы должны как минимум получать отклик в виде успеха/неуспеха. Из command bus можно возвращать много интересного и это никак не противоречит CQRS: версию aggregate root, список ошибок, событий, id-шники событий (если у тебя event sourcing), etc.

Даже если проводить некоторую аналогию с INSERT, как ты любишь, INSERT может вернуть ошибки, он неявно возвращает новый id (AUTO_INCREMENT), он также неявно возвращает список warning'ов. Смысл CQRS не в том, что метод обязан быть void, а в том, что мы работаем с разными концептуальными моделями при записи и чтении: в первом случае это реальная модель, а при чтениях — лишь её какая-то проекция, которая может очень сильно отличаться от оригинала.

 

[grigori]

да, путаница CQS и CQRS у меня есть, они даже в wiki в одной статье описаны как синонимы,
а представления про fire and forget - нет, я понимаю нужность отклика

 

[grigori]

https://martinfowler.com/bliki/CQRS.html


Вероятно, ты путаешь с CQS. CQS относится к CQRS примерно как диверсификация рисков в экономике к, допустим, поговорке «не клади все яйца в одну корзину». Идея одна, но семантические уровни разные: в одном речь про методы, а в другом — как раз про модели.

Существует распространённое заблуждение про то, что command bus — это «fire and forget», что commands «one way only». Это не так. Команды как раз по своей природе синхронны, мы должны как минимум получать отклик в виде успеха/неуспеха.

таки есть и другое мнение
https://microservices.io/patterns/data/cqrs.html
CQRS - как принцип построения микросервисной архитектуры, проблема "fire and forget" возникает, и решается в "хореографии" дополнительным кодом отработки отката операций назад по цепочке во всех задействованных сервисах

 

[fixxxer]

CQRS сам по не обязывает так делать, это принцип разделения и не более того. Паттерн сам по себе не запрещает взять и завернуть всю вот эту байду в большую транзакцию. Здравый смысл и вероятность дедлоков могут запрещать, это уже другой вопрос

 

[Вурдалак]

таки есть и другое мнение
https://microservices.io/patterns/data/cqrs.html
CQRS - как принцип построения микросервисной архитектуры, проблема "fire and forget" возникает, и решается в "хореографии" дополнительным кодом отработки отката операций назад по цепочке во всех задействованных сервисах

Я говорил про команды: там «fire and forget» быть не должно. Этот термин («fire and forget») достаточно часто использовался в контексте command bus, но на мой взгляд (и не только на мой — мнение того же Greg Young'а) это некорректно.

P.S. >CreateOrder
Заказы обычно размещают (to place), реже используют «to make». Немного напрягает, когда пытаются использовать терминологию, звучащую как rocket science, а отголоски CRUD до сих пор остаются. Это дерьмо очень плотно вошло в индустрию, если для многих «to create an order» звучит нормально.