теперь будет у юзера new UserEmail

вернее

теперь будет у юзера new UserEmail

class User { void changeEmail(UserEmail email) => _email = email; }

UserEmail это VO. обычная строка, надо валидировать строку еще. С одной стороны, второй вариант вроде удобнее, однако, мы раскидываем инициализацию new UserEmail по всему проекту

Лучше с UserEmail. Так интерфейс объекта нагляднее

fucntion email (UserEmail $email) $this->email = $email

@shindakioku а почему void?

fluent interface вышел из моды :) зачем этому методу что-то возвращать?)

Кстати. а почему UserEmail? не просто Email?

@shindakioku а почему void?

Да там вообще сеттер должен быть

@shindakioku а почему void?

CQRS :D

CQRS :D

чё?)

Кстати. а почему UserEmail? не просто Email?

> public function change(UserEmail $email) : self

чё?)

разделение на команду/запрос

> public function change(UserEmail $email) : self

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

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

Это его код

и возвращал новый объект себя

разделение на команду/запрос

спасибо, капитан) а каким боком ты его сюда приплёл?)

> public function change(UserEmail $email) : self

это то я понял. я просто про название класса. зачем оно названо UserEmail? потом надо будет CustomerEmail? CompanyEmail?

спасибо, капитан) а каким боком ты его сюда приплёл?)

void же

void же

и?

это то я понял. я просто про название класса. зачем оно названо UserEmail? потом надо будет CustomerEmail? CompanyEmail?

@BonBonSlick

class User { void changeEmail(UserEmail email) => _email = email; }

потому что вот это команда

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

это то я понял. я просто про название класса. зачем оно названо UserEmail? потом надо будет CustomerEmail? CompanyEmail?

скорее всего он просто не до конца пока понял для чего они нужны

потому что вот это команда

class User { Email _email; set email(Email e) => _email = e; } А это? :)

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

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

но, ладно) отбросим все сомнения в том, что cqrs сюда притянут за яйца: команда может возвращать результат.

шах и мат.

но, ладно) отбросим все сомнения в том, что cqrs сюда притянут за яйца: команда может возвращать результат.

какой результат?

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

true или false? ))

вопрос не в том, какой. А в том, что может.

вопрос не в том, какой. А в том, что может.

в твоем маня мирке может, ок

в твоем маня мирке может, ок

в любом мирке. Включая его создателей

Сейчас бы за cqrs срачи разводить в 2018ом

вопрос не в том, какой. А в том, что может.

я пытаюсь понять какой именно результат в твоем мире возвращает команда User::changeEmail

да cqrs нынче попса похлеще mvc в бывалые годы)

я пытаюсь понять какой именно результат в твоем мире возвращает команда User::changeEmail

контекст почитай

контекст почитай

это я тупой и ничего не понимаю, или Максим чтото сказал, не пытаясь обьяснить свою точку зрения?

максим задал вопрос, каким образом к объяснению войда приплели cqrs

class User { void changeEmail(UserEmail email) => _email = email; }

причем аргументировал тем, что просто *может* ,при всем при этом, мои уморассуждения были привязанны иключительно к этому контексту ? а не обобщены

если у меня юзерь иммутабелен и смена емейла возвращает новый объект юзеря - это уже не cqrs?)

если у меня юзерь иммутабелен и смена емейла возвращает новый объект юзеря - это уже не cqrs?)

наши закостенелые мозги не смогли даже предположить что юзер может быть не сущностью а VO

но это все равно странно :)

ну так пускай умный человек объяснит идиоту, за каким хером он за cqrs накинул :)

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

круто. мы буковки подгоняем под то, что нужно в текущий момент

миру звездец)

свободномыслящий Максим развел спор ради спора :)

свободномыслящий Максим развел спор ради спора :)

да я вопрос задал) в ответ херню какую-то услышал. Ещё и слив до кучи.

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

CQRS :D

CQS а не CQRS

CQS а не CQRS

верно

вот он и возмутился

коль так, тогда my bad

Максима легко возбудить фразами CQRS, actor model, event sourcing и "платежки"

Максима легко возбудить фразами CQRS, actor model, event sourcing и "платежки"

ddd ещё)

обьясните кратко разницу

CQRS CQS

ох

Сергей, форвардни просто то, что мне писал)

универсальный ответ получился ж)

CQS - разделение методов ОДНОГО ИНТЕРФЕЙСА на команды и запросы CQRS - разделение команд и запросов по разным интерфейсам

CQS - разделение методов ОДНОГО ИНТЕРФЕЙСА на команды и запросы CQRS - разделение команд и запросов по разным интерфейсам

сойдет

универсальный ответ получился ж)

лень скролить, если есть под рукой форвардни, я себе добавлю в список

да не. я понял. спасибо

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

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

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

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

а то я слышал варианты, что CQRS - это если только c ES. вот и спросил

а то я слышал варианты, что CQRS - это если только c ES. вот и спросил

даже если в таком контексте, es просто рядом стоит. никак не влияя

а то я слышал варианты, что CQRS - это если только c ES. вот и спросил

CQRS без ES - можно, ES без CQRS - нельзя

CQRS без ES - можно, ES без CQRS - нельзя

ну это очевидно :)

коль пошла такая пьянка: а почему собственно es без cqrs нельзя?)

а что такое ES ?

event sourcing

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

коль пошла такая пьянка: а почему собственно es без cqrs нельзя?)

А как?

коль пошла такая пьянка: а почему собственно es без cqrs нельзя?)

ну потому что тебе нужны проекции, а значит пишешь ты в один "интерфейс" а читать будешь из другого.

ну то есть без такого рода разделения сделать ES в целом невозможно

ну потому что тебе нужны проекции, а значит пишешь ты в один "интерфейс" а читать будешь из другого.

ну, в целом, как бывалому наркоману, мне никто не запрещает не использовать проекции.

ну, в целом, как бывалому наркоману, мне никто не запрещает не использовать проекции.

ну если твоему приложению не надо читать вообще ничего - то да)

но тогда мы имеем дело только с командами

Мы можем читать из write model

ну и опять же стэйт самой write модели это тоже проекция)

ну и опять же стэйт самой write модели это тоже проекция)

вот :)

ну и опять же стэйт самой write модели это тоже проекция)

Интерфейс один

отсюда вопрос, который накинул выше и на который ответ не получил)

Интерфейс один

ну далеко на этом ты ж не уедешь) но да, в теории можно. Просто я не уверен можно ли это называть event sourcing)

ибо sourcing как такового нет

можно исправить фразу и сказать, что ES без CQRS бессмысленен

что в приличном обществе можно приравнять к слову нельзя

можно исправить фразу и сказать, что ES без CQRS бессмысленен

да, так лучше

ибо sourcing как такового нет

Почему?