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

НЕЗАВИСИМЫЕ

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

Пытаться применить нет, но сообщить о его просрочке можно

так что можно опять же сначала проверить все прекондишены а уже потом сраждаться с инвариантами. И получить список ошибок для прекондишенов (это просто) а с инвариантами просто фэйлить по одной ошибке. Поскольку у тебя применение промокода все же зависит от брони

Я это и предложил, вынести проверки прекондишенов в отдельный метод

еще раз - прекондишены и инварианты - разные вещи

ой все короч

))

Ты почти понял меня)

прикол инвариантов в том что у тебя врядли в одной бизнес операции будут независимые инварианты. Как следствие - говорить о получении "списка" нарушений инвариантов глупо

инварианты - они как бы инварианты системы

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

Ты согласен с тем что для атомарного перехода от одного состояния к другому с соблюдением всех инвариантов может потребоваться проверка 2 и более независимых условий?

независимых - нет. Потому что переход от одной проверки к другой требует изменения состояния.

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

Чтобы проверить наличие одной ноги не нужно менять состояние

еще раз... 1. конфликт в промокодах (один промокод остался) и нет конфликта по местам - если проверки "независимы" то фэйл с промокодами не должен влиять на бронь. 2. конфликт с местами, промокодов всем хватает - бронь не будет произведена 3. конфликт и с местами и с промокодом - ты не сможешь забронировать а стало быть не сможешь применить промокод. Как следствие зафэйлится всегда только одна операция (нету конфликта). Что делает эти проверки зависимыми

Проверки зависимы если возможность выполнить одну проверку появляется после совершения другой проверки. Например, 1. Ввел ли пользователь купон, 2. Существует ли купон. 3. Просрочен ли купон. В нашем случае чтобы проверить купон, не обязательно бронить место, значит результат проверки можно показать сразу независимо от того, свободно ли место

все это - прекондишены а не инварианты.

их можно проверять отдельно

опять же - ситуация (раз уж ты за конверсию топишь) - я ошибся с промокодом и выбрал места. Нажал "забронировать", и система мне такая "сорян дружок, ты ввел невалидный промокод, но ты еще мог забронить" и пока я читаю это сообщение бронирует кто-то другой

а это были последние места которые я считаю удобными для себя и вообще в пень твой сервис - посмотрю в онлайн кинотеатре дома

короч, еще раз - ты решаешь проблему, которая появилась у тебя из того, как ты организовал UI и работу с оным. Внезапно у тебя реализация клиента влияет на бизнес

при этом мои варианты ты называешь негибкими - и в этом я вижу проблему

проблеме при этом не первый день и её давно уже решили

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

так а в чем проблема, чето аля return Promise.all([ firstOp(request), secondOp(request), thirdOp(request, smthElse) ]).then(() => response.ok(), e => response.error(e))

другое дело, что обычно это не нужно или даже нужно не это)

при этом мои варианты ты называешь негибкими - и в этом я вижу проблему

Вопрос еще не закрыт, продолжим потом, мне стало интересно)

сначала была протокурица, потом курирое яйцо и потом уже курица.

Пхпшники, вас можно поздравить?

Rfc с типами на свойство приняли

ты осоздал, мы уже неделю назад это дело обмывали

А де мои одинарные кавычки?

ты осоздал, мы уже неделю назад это дело обмывали

Сук

всеравно с типами в пыхе все плохо и будет плохо и ничего не поменяется

всеравно с типами в пыхе все плохо и будет плохо и ничего не поменяется

С типами?

Это те, которые встроенны в ядро и не умеют ничего?

типа всеравно придется писать что-то типа /** * @var Post[] */ private array $posts;

А ты снова про дженерики)

Меня больше угнетает то, что у типов нету объектов

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

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

Эта да

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

Вряд ли они тебе закинут их до 8ой

Вряд ли они тебе закинут их до 8ой

проблема - желание проверять типы в рантайме. Потому что они хотят их хоть где-нибудь проверять)

а не просто синтаксис

а не просто синтаксис

Мечтай ?

Мне вот недавно пришлось снова на пхп пописать денек, как же я горел ?

Мне вот недавно пришлось снова на пхп пописать денек, как же я горел ?

Плохому танцору яйца мешают

Плохому танцору яйца мешают

Ясн

Плохому танцору яйца мешают

И кирзовые сапоги еще бывает совсем не помогают гранд батман делать

все это - прекондишены а не инварианты.

Блин я все пропустил, но было интересно прочитать дискуссию. Уже поздно, но напишу сейчас. Вот мой кейс: Есть рестораны, у них менеджеры. Менеджеры заказывают курьеров. Курьер принимает заказ через телеграм бота. Но вот инвариаты, которые должны не должны провалиться перед действием: 1. Курьер должен быть в XXX минутах от места куда нужно прибыть, на момент когда он принимает заказ. 2. Он должен состоять в одной группе с рестораном (менеджер этого сервиса может исключить курьера из группы, уже после того как курьеру прилетело уведомление о заказе) 3. Банально проверить не взял ли уже другой курьер этот же заказ. => нужно, чтобы курьер мог понять все причины, из-за чего у него не получилось взять заказ. Возможно логично, что ему не нужно знать более одной причины. НО тут требование заказчика. Или вот возможно более явный пример: Человек оформляет перевод, нужно проверить что тот кому он переводит не заблокирован и разрешает переводы к себе а также проверить, что оставшегося после перевода баланса хватить чтобы погасить ежемесячные расходы(тут не буду углубляться, эта общая суть) В целом идея, что проверка - это не инвариант - наверное правильная мысль. Типа по какому нибудь CQRS мы можем из команды ничего не возвращать, только прошла операция или нет. А уже потом делать запрос на предмет что именно не так.

.

Блин я все пропустил, но было интересно прочитать дискуссию. Уже поздно, но напишу сейчас. Вот мой кейс: Есть рестораны, у них менеджеры. Менеджеры заказывают курьеров. Курьер принимает заказ через телеграм бота. Но вот инвариаты, которые должны не должны провалиться перед действием: 1. Курьер должен быть в XXX минутах от места куда нужно прибыть, на момент когда он принимает заказ. 2. Он должен состоять в одной группе с рестораном (менеджер этого сервиса может исключить курьера из группы, уже после того как курьеру прилетело уведомление о заказе) 3. Банально проверить не взял ли уже другой курьер этот же заказ. => нужно, чтобы курьер мог понять все причины, из-за чего у него не получилось взять заказ. Возможно логично, что ему не нужно знать более одной причины. НО тут требование заказчика. Или вот возможно более явный пример: Человек оформляет перевод, нужно проверить что тот кому он переводит не заблокирован и разрешает переводы к себе а также проверить, что оставшегося после перевода баланса хватить чтобы погасить ежемесячные расходы(тут не буду углубляться, эта общая суть) В целом идея, что проверка - это не инвариант - наверное правильная мысль. Типа по какому нибудь CQRS мы можем из команды ничего не возвращать, только прошла операция или нет. А уже потом делать запрос на предмет что именно не так.

1-ое и 2ое вроде как прекондишены а не инварианты. 3-ее - можно проверить но опять же будут ситуации с конкурентным доступом которые ты никак нормально не разрулишь.

1-ое и 2ое вроде как прекондишены а не инварианты. 3-ее - можно проверить но опять же будут ситуации с конкурентным доступом которые ты никак нормально не разрулишь.

Почему прекондишены, что это значит? Мы же должны проверить эти все три условия перед изменением состояния, верно? Это все должно происходить при одном и том же снапшоте состояния жи.

конкурентным доступом которые ты никак нормально не разрулишь. - блокировки?

Почему прекондишены, что это значит? Мы же должны проверить эти все три условия перед изменением состояния, верно? Это все должно происходить при одном и том же снапшоте состояния жи.

вот у тебя есть пред условия, пост условия и инварианты. Что есть что?

и можно ли говорить о инвариантах если состояние не меняется?

и можно ли говорить о инвариантах если состояние не меняется?

Ну мы проверяем все три инварианта, когда делаем снап состояния на момент запроса. Если три инварианта выполяются мы меняем стейт

вот у тебя есть пред условия, пост условия и инварианты. Что есть что?

Вообще множественные инварианты (инвариант как бы по сути не один, но проверок для его удовлетворения несколько) на мой взгляд таких случаев много оч много. Например вот у Вернона есть такие: https://github.com/VaughnVernon/IDDD_Samples/blob/05d95572f2ad6b85357b216d7d617b27359a360d/iddd_collaboration/src/main/java/com/saasovation/collaboration/domain/model/forum/Forum.java#L79 Я пытаюсь понять, как ты отличаешь пред условия, пост условия и инварианты, на примерах, что есть что и почему? Для меня это все инварианты

инварианты - это когда у нашего объекта есть состояние. И эти самые инварианты - это некие предикаты (утверждения, условия) которые описывают непротиворечивый стэйт этого объекта. Помимо инвариантов (которые относятся к всему объекту, или системе) есть еще прекондишены и пост кондишены (пред условие - на вход нам нужно подать айдишку юзера, который существует, не заблокирован и все такое. Пост условие - если все хорошо - состояние поменяется определенным образом). То есть само по себе изменение состотяние - это уже пост условие. Главное что бы при изменении состояния все предикаты описывающие инварианты оставались истинными.

Давай теперь посмотрим на твой пример. У нас есть три предиката, которые должны быть истины на момент заказа курьера: - курьер должен быть в XXX минутах от места - курьер должен состоять в группе - курьер должен быть свободен Даже если мы каким-то образом проверим все три условия и выплюнем менеджеру ошибку что мол одно из условий нарушено - мы никак не сможем гарантировать что за тот промежуток времени состояние не поменяется еще раз и не произойдет еще ошибки. Потому я считаю что глупо пытаться оптимизировать эту часть работы, ибо в целом никому от этого удобнее в реальности не будет. Одна ошибка или все три - результат для менеджера один и тот же - он не может передать заказ этому курьеру. В целом мы всегда можем проверить все три условия отдельно, оставляя лишь пограничные ситуации: - когда курьер вот-вот отъедит слишком далеко - курьер вот-вот примет заказ - курьера вот-вот исключат из группы (как по мне самый маловероятный сценарий из трех) Что бы все три ивента произошли одновременно (или два из трех) - менеджеру твоему должно сильно Не повести. А если мы говорим о хэппи флоу - можно отдельно проверить все три условия и выплюнуть менеджеру состояние. В целом, мы вообще не должны отображать ему варианты, которые приведут к нежелательному результату. Синхронизировать стэйт на клиенте у менеджера что бы тот видел сколько кому ехать, кто стал занятым и т.д. Все что бы уменьшить окно по времени когда могут возникать эти вот пограничные ситуации.

инварианты - это когда у нашего объекта есть состояние. И эти самые инварианты - это некие предикаты (утверждения, условия) которые описывают непротиворечивый стэйт этого объекта. Помимо инвариантов (которые относятся к всему объекту, или системе) есть еще прекондишены и пост кондишены (пред условие - на вход нам нужно подать айдишку юзера, который существует, не заблокирован и все такое. Пост условие - если все хорошо - состояние поменяется определенным образом). То есть само по себе изменение состотяние - это уже пост условие. Главное что бы при изменении состояния все предикаты описывающие инварианты оставались истинными.

на вход нам нужно подать айдишку юзера, который существует, не заблокирован и все такое. - ты как бы это делаешь не в домене или в отдельном запросе? Все-таки я не пойму чем отличается инварианты от прекондишенов. Вот на моем примере с курьерами, почему гелолокация и пристуствие в группе это прекондишены, а не инварианты?

то есть так же как ты бы делал непосредственно при изменении - ты можешь предоставить отдельные методы для проверки каждого из условий.

на вход нам нужно подать айдишку юзера, который существует, не заблокирован и все такое. - ты как бы это делаешь не в домене или в отдельном запросе? Все-таки я не пойму чем отличается инварианты от прекондишенов. Вот на моем примере с курьерами, почему гелолокация и пристуствие в группе это прекондишены, а не инварианты?

не. это все ж инварианты системы.

Давай теперь посмотрим на твой пример. У нас есть три предиката, которые должны быть истины на момент заказа курьера: - курьер должен быть в XXX минутах от места - курьер должен состоять в группе - курьер должен быть свободен Даже если мы каким-то образом проверим все три условия и выплюнем менеджеру ошибку что мол одно из условий нарушено - мы никак не сможем гарантировать что за тот промежуток времени состояние не поменяется еще раз и не произойдет еще ошибки. Потому я считаю что глупо пытаться оптимизировать эту часть работы, ибо в целом никому от этого удобнее в реальности не будет. Одна ошибка или все три - результат для менеджера один и тот же - он не может передать заказ этому курьеру. В целом мы всегда можем проверить все три условия отдельно, оставляя лишь пограничные ситуации: - когда курьер вот-вот отъедит слишком далеко - курьер вот-вот примет заказ - курьера вот-вот исключат из группы (как по мне самый маловероятный сценарий из трех) Что бы все три ивента произошли одновременно (или два из трех) - менеджеру твоему должно сильно Не повести. А если мы говорим о хэппи флоу - можно отдельно проверить все три условия и выплюнуть менеджеру состояние. В целом, мы вообще не должны отображать ему варианты, которые приведут к нежелательному результату. Синхронизировать стэйт на клиенте у менеджера что бы тот видел сколько кому ехать, кто стал занятым и т.д. Все что бы уменьшить окно по времени когда могут возникать эти вот пограничные ситуации.

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

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

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

Пока оставим что нужно уведомлять о результате всех трех проверок инварианта

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

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

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

По списку да, тут наверное действительно не очень нужно это - согласен. Тем более что можно потом сделать проверку уже query запросом. Буду искать еще примеры где мне нужно было вернуть сразу весь список ошибок, без прекондишенов. Если найду отпишу :)

я выше описал почему считаю это бесполезной затеей. Но тебе никто не мешает сделать 3 проверки и если одна из них зафэйлилась кинуть общее исключение.

которое может уже включать в себя информацию о результатах всех трех ошибок

я выше описал почему считаю это бесполезной затеей. Но тебе никто не мешает сделать 3 проверки и если одна из них зафэйлилась кинуть общее исключение.

Во

Я только думал как это технически сделать, чтобы норм выглядело

res += isValidFirstCond() res += isValidSecondCond() res += isValidThirdCond() if(res.hasError()) throw ArgException(res.errors) Как то не оч наверное?

почему нет?

но в целом - я не сталкивался с такими потребностями

почему нет?

Когда кода больше с доменными понятиями - то как будто это усложняет понимание и читаемость самой предметной области

Но хотя жертвовать приходится чем то если это реально нужно в редких случаях

Спасибо

Еще последнее

ну то есть список ошибок - это можно на уровне валидации входящих данных проверить. Дальше уже списка ошибок быть не может

ну то есть список ошибок - это можно на уровне валидации входящих данных проверить. Вот тут можешь описать подробнее как ты это делаешь? Например та же история с email который мы потом создаем VO Email c проверкой при создании.

Когда кода больше с доменными понятиями - то как будто это усложняет понимание и читаемость самой предметной области

говно всегда можно вынести в приватный метод

А потом создаем VO Name и тоже првоеряем при создании

ну то есть список ошибок - это можно на уровне валидации входящих данных проверить. Вот тут можешь описать подробнее как ты это делаешь? Например та же история с email который мы потом создаем VO Email c проверкой при создании.

ну вот email с проверкой при создании - это из вне, оно уже на вход приходит все такое валидное и готовое юзаться

говно всегда можно вынести в приватный метод

Я больше про имена, по типу где res и res.hasError

function foo(name: Name, email: Email)

Я больше про имена, по типу где res и res.hasError

expectations.failed

хз) домен твой чистым абсолютно никогда не будет) сам понимаешь)

ну вот email с проверкой при создании - это из вне, оно уже на вход приходит все такое валидное и готовое юзаться

Как мне вывести ошибки обо всех и Name и Email? Те получается попробовали создать VO Name зафейлились, сохранили ошибку, попробовали Name создать, опять зафейлились, потом вывели все эти ошибки? Не по уродски?

вот если бы ты DSL писал свой - то можно было бы сделать чистый домен.

а так у тебя всегда будут технические штуки в коде

Как мне вывести ошибки обо всех и Name и Email? Те получается попробовали создать VO Name зафейлились, сохранили ошибку, попробовали Name создать, опять зафейлились, потом вывели все эти ошибки? Не по уродски?

это снаружи делается. Это как раз целиком и полностью прекондишены, причем выраженные явно типами

нада учить Скалу)