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

потом по комиту их некто из этого синглтона достает и делает свои дела

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

А если несколько потоков

паблишит, контейнер дергает

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

Только свои ивенты собирает?

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

Я понять всё никак не могу что это такое

Можно на пальцах?

А если несколько потоков

все решается в зависимости от того, как вы их делите

все решается в зависимости от того, как вы их делите

Веб. Тредпул же. Доткор.

const DomainEvents = { record(entity, event) getRecorded() }

потом UoW сам собирает нужные ему сущности

Стартует с команды "выполни что-то большое и длинное". И начинает по шагам выполнять. Фаерит первую команду, подписывается на событие, которая оная порождает. Получила событие - зафаерила новую команду и т.д.

Стартует с команды "выполни что-то большое и длинное". И начинает по шагам выполнять. Фаерит первую команду, подписывается на событие, которая оная порождает. Получила событие - зафаерила новую команду и т.д.

Ммм, понял. Типа оркестратор команд.

если несколько потоков, то это уже ваши решения про локи и все такое

если несколько потоков, то это уже ваши решения про локи и все такое

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

сагу можно легко представить в виде блок-схемы: если/то

С бэком

сагу можно легко представить в виде блок-схемы: если/то

Весело такое дебажить

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

так что именно нехорошо?

И тестами крыть

Весело такое дебажить

быстро привыкаешь

тестами крыть аще великолепно

тестами крыть аще великолепно

Есть пример на гитхабе?

тестов саги? нет. руки никак не дойдут демку сделать

у тебя каждная команда отвечает за 1 единственную задачу. В чём сложность её тестирования?)

так что именно нехорошо?

А то, что у нас процесс живет условно вечность. И в этом процессе куча потоков. Соответственно если синглтон делать - то все потоки туда писать будут.

у тебя каждная команда отвечает за 1 единственную задачу. В чём сложность её тестирования?)

Я про тесты саг)

А то, что у нас процесс живет условно вечность. И в этом процессе куча потоков. Соответственно если синглтон делать - то все потоки туда писать будут.

и?)

ну в чём сложность-то? протестить что при вызове метода someEvent создастся команда DoSome() ?

и?)

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

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

я вытягиваю под конкретную сущность

чужие не увижу

ну в чём сложность-то? протестить что при вызове метода someEvent создастся команда DoSome() ?

А если в её процессе ошибка, то ролбэкать ещё

и?

и?

Ну просто это много тестов)

чем роллбэк будет отличаться от "протестить что при вызове метода someEvent создастся команда DoSome() ?"

много действий - много тестов

много действий - много тестов

Тоже верно)

я вытягиваю под конкретную сущность

То есть на конретную прям - типа юзер такой-то с таким-то id?

Сорри если вопросы дурацкие - я в этом всём разобраться просто пытаюсь.

чую стоит тебе ещё про pessimistic/optimistic lock посмотреть

чую стоит тебе ещё про pessimistic/optimistic lock посмотреть

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

То есть на конретную прям - типа юзер такой-то с таким-то id?

да, unit of work дает тебе все сущности, которые были в текущей транзакции, ты по ним достаешь ивенты

всё знаешь, всё понимаешь...) вопрос-то в чём тогда?) соедение тайные знания и велкам)

всё знаешь, всё понимаешь...) вопрос-то в чём тогда?) соедение тайные знания и велкам)

Вот пытаюсь познать всю эту cqrs'но-ddd'шную магию)

зря ты тут cqrs и ddd в 1 флакон налил) беги лучше)

да нет магии никакой)

Ну для меня пока что есть)

зря ты тут cqrs и ddd в 1 флакон налил) беги лучше)

Одно другому мешает?

на столько, на сколько мягкое может мешать тёплому)

на столько, на сколько мягкое может мешать тёплому)

То есть никак)

А если несколько потоков

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

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

А синглтон один на всех

А синглтон один на всех

ну а агрегат один на тред)

ну а агрегат один на тред)

А штука куда ивенты складываешь, если она синглтон - то она одна для всех потоков и всех агрегатов

вы немного зациклились

А штука куда ивенты складываешь, если она синглтон - то она одна для всех потоков и всех агрегатов

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

ну и нет, ты можешь сделать на кажды поток свой "сингелтон"

будет регистри)

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

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

все

короч все зависит от того как сделаешь - просто почитай как люди делают

короч все зависит от того как сделаешь - просто почитай как люди делают

Ок. Да про DI и лайфтаймы я знаю. Просто не охота синглтон, потому что это конкуррентный rw. А это блокировки. А если бы он был InstancePerRequest, то и конкуррентного доступа нет, и блокировок, и синхронизаций. Сугубо с практической точки зрения смотрю) Но поищу как другие делают) А то забодал уже вас уже своими вопросами наверное)

Ок. Да про DI и лайфтаймы я знаю. Просто не охота синглтон, потому что это конкуррентный rw. А это блокировки. А если бы он был InstancePerRequest, то и конкуррентного доступа нет, и блокировок, и синхронизаций. Сугубо с практической точки зрения смотрю) Но поищу как другие делают) А то забодал уже вас уже своими вопросами наверное)

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

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

Пробовал. Смотрю - и не нравится. Мс предлагает при сохранении изменений в EF с ивентами работать. Тоже такое не понравилось - потому что в одной транзакции сохранений может быть несколько.

В общем буду дальше копать)

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

char->n, line->n else?

locatation to displace

code to simple fragmenets

I wonder can I a rewrite php as just bunch of letters

Есть ли какая-то принципиальная разница между внедрением объекта-значения и его композицией? То есть вместо class Notification { public function __construct(string $message, Nick $recipient, Nick $sender) } было бы class Notification { public function __construct(string $message, string $recipient, string $sender) { $this->recipient = new Nick($recipient); $this->sender = new Nick($sender); } }

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

Во втором случае Notification знает как создавать Nick И тут напрашивается вопрос сам собой: зачем ему это знать ？

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

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

ну и еще - Nick по идее уже где-то хранится, и упрощение за счет введение этого VO заключается в том, что все правила валидного никнейма заключены в нем

по факту в клиентском коде у тебя будет что-то типа Notification::new($message, $profile->nickName(), $sender)

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

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

Имеется в виду какой-нибудь SuccessNotification, где сообщение задаётся в конструкторе и извне не фигурирует?

Имеется в виду какой-нибудь SuccessNotification, где сообщение задаётся в конструкторе и извне не фигурирует?

ну я так к примеру