#жизнь_говно

Посоны, специально для вас стикерпак

и это тоже

сук пока читал вашу хуйню напутал события и команды

сук пока читал вашу хуйню напутал события и команды

бросай cqs) до добра не доведёт)

бросай cqs) до добра не доведёт)

я только начал вникать

это ахуенно

я прям переосмысли подход к разработке

В чем кстати разница cqs и cqrs?

т.е я понимаю что сейчас у меня может возникнуть период, когда я буду чрезмерно его использовать(типо как "ООП головного мозга" при знакомстве с паттернам) но подход очень хорош

что бы лишний раз не копипастить)

cqs действует на уровне методов/функций, cqrs повыше

для cqs не требуется разделение никакого. у тебя есть один интерфейс с двумя методами. Один для сайд эффектов но не возвращающий ничего и второй для чтения. То есть мы тут регламентируем ограничения для методов. Пример метода/функции которая нарушает CQS - array_pop.

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

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

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

Схоронил

fullNameChange VS setFullName ну да, +/- буквы по-разному расставлены)

что это за трэш:?

каждому своё) я привык всегда контролировать всё. И уж тем более типы в том языке, на котором жизнь заставила писать :)

может ты dto как то не так используешь?)

или я, как вариант

может ты dto как то не так используешь?)

ну так-то по логике вещей твоё описание ближе к правде

что бы лишний раз не копипастить)

эххххх, годнотааааа

я тоже предпочитаю в дто держать валидацию но по другой причине - они ближе к контроллеру и отдать ошибку на клиент проще

вот да, просто у меня дтошки всегда в валидном состоянии. Говна не возят

вот да, просто у меня дтошки всегда в валидном состоянии. Говна не возят

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

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

поэтому изначально и написал: каждому своё)

Maksim @arturpanteleev , согласен, насчет сеттеров в вашей точке зрения больше смысла)

я тоже предпочитаю в дто держать валидацию но по другой причине - они ближе к контроллеру и отдать ошибку на клиент проще

валидируй реквесты

еще до мэппинга на dto

еще до того как они в контроллер попали)

валидируй реквесты

ещё не дошло)

плюс формы плюс доп данные

Maksim @arturpanteleev , согласен, насчет сеттеров в вашей точке зрения больше смысла)

в сеттерах нет ровным счетом никакого смысла

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

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

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

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

валидируй реквесты

это еще зачем?

это еще зачем?

правильно, не валидируй входящие данные

зачем слою работающему с http протоколом что то знать о том, что имя должно быть строкой а не цифрой

зачем слою работающему с http протоколом что то знать о том, что имя должно быть строкой а не цифрой

потому что... это именно его обязанность?

тебе надо хорошо понимать что валидация бывает разной

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

и это разные вещи

правила в духе "тут должна быть строка а тут число в пределах диапозона" - это как раз таки хорошо вписывается.

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

вот только далеко не всегда оно мэпится 1:1

я тупанл, по факту также делаю в контроллере, просто там 90% проверки на непустое значение обязательных полей у меня

да понял

я тупанл, по факту также делаю в контроллере, просто там 90% проверки на непустое значение обязательных полей у меня

А на длину и рэнж не проверяешь что ли? Та же хуита может прилететь.

я тупанл, по факту также делаю в контроллере, просто там 90% проверки на непустое значение обязательных полей у меня

ну так я предлагаю ДО контроллера это делать)

А на длину и рэнж не проверяешь что ли? Та же хуита может прилететь.

тут тоже могут быть нюансы

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

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

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

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

ну так я предлагаю ДО контроллера это делать)

так у меня контроллер самый низкий слой...то есть я в нем обрабатываю $_POST из которого формирую DTO и передаю в commandBus

у меня в реализации валидация описана в командах в виде аннотаций. дёшево и сердито

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

мне нравито то как ты это рассказываешь - сразу чувствуется дух профессианализма

В плане валидации лучше перебдеть, чем недобдеть. Как говорится: "Never trust user input"

В плане валидации лучше перебдеть, чем недобдеть. Как говорится: "Never trust user input"

тут никто не агитирует за то что не надо валидировать - вопрос где это делать

мне нравито то как ты это рассказываешь - сразу чувствуется дух профессианализма

Давай без сарказма)

тут никто не агитирует за то что не надо валидировать - вопрос где это делать

А тут уже зависит от того что именно мы валидируем. Есть штуки, значимые для слоя сущностей, а есть штуки, значимые для инфраструктуры. Где оно имеет значение - там и валидируем.

А тут уже зависит от того что именно мы валидируем. Есть штуки, значимые для слоя сущностей, а есть штуки, значимые для инфраструктуры. Где оно имеет значение - там и валидируем.

и именно это мы и обсуждаем. Что валидация разная, что в разных местах надо делать по разному

у меня в реализации валидация описана в командах в виде аннотаций. дёшево и сердито

но это, очевидно, первый рубеж валидации. бизнесовые аспекты уже сильно позже идут

короч разберись что мы обсуждаем

Что-то не пойму. С 23 числа сообщений не было?))

Не посчитайте за оскорбление администрации, но я нашёл однодумцев @fesor

ERROR: S client not available

Извините, больше не буду в картинки)

creepy

Не посчитайте за оскорбление администрации, но я нашёл однодумцев @fesor

да, моя фотка так и родилась)

лет 5 назад

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

*я женился это бищнес процесс ссобытиями в тч смены имнени в паспорте

не надо в контроллере делаь сеты

но делать их надо

но делать их надо

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

но сеттеры тут не нужны

смена паспорта - это по сути создание новой сущности

ну и многие другие взаимодействия можно заменить с мутации через сеттеры на порождение новых сущностей и vo

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

creepy

Скорее crepy ;)

смена паспорта - это по сути создание новой сущности

id юзера менять не стоит )

номер паспорта я хз меняется или нет

но есть куда более простые изменения

при смене фам у юзера точно не стоит менять айди юзера

это не программистам решать, как правило)

кек

ну, иногда приходится быть продукт овнером тоже

id юзера менять не стоит )

а ты когда паспорт меняешь у тебя айдишка меняется?)

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

всё так и ты говоришь добавю юзеру новый паспорт

но у нас нормализация реальности

у пользователя есть имя в паспорте

а есть имя пользователя

мисс/миссис

госпожа

ув.

это не обязательно отдельные сущьности

и едвали там нужен экшен. как не назови по сути будет сет