но он уже чисто инфраструктурные изменения мутит

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

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

а если у меня 10 сущностей на которые это событие влияет

Aply по логике вызывается внутри агрегата. А потом, после того, как стрим засейвится, события попадут в бас и будкт розданы желающим

Ты как собираешься событиями из шины стейт менять?

Событие - то, что произошло. Т.е. изменение аргрегата уже было совершено. А у тебя что первичным выходит?

А восстанавливать агрегат из стрима как?)

я пока не разобрался

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

т.к они хранятся только лдя пост обработки

т.е реплаи мы не мутим

и если бы не требования закона они вообще бы не хранились, а просто в comet посылались

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

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

Внутри ты обновляешь стейт write model

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

Общие слушатели просто для другого.

сейчас мне надо пробросить событие, чтобы чуваки из другого отдела(другйо bounded context по сути) смогли себе сохранить коммент

это явно нужно делать в басе

я так вижу

йоу, коллеги! странный вопрос в чате: все ли параметры конструктора можно считать "зависимостями"?

йоу, коллеги! странный вопрос в чате: все ли параметры конструктора можно считать "зависимостями"?

как скаляр (к примеру) может быть зависимостью?

как скаляр (к примеру) может быть зависимостью?

а в чем разница скалар или не скаляр?

как скаляр (к примеру) может быть зависимостью?

А скаляр уже не объект?)

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

ладно, на мысль вы меня натолкнули окей, а что тогда есть зависимость?

это явно нужно делать в басе

Вот как раз события туда попадают после aply

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

если считать зависимостью что-либо, чья реализация (но не значение) влияет на поведение объекта - тогда это всякие сервисы и по такой логике все, что имеет только значение - не является зависимостью

если считать зависимостью что-либо, чья реализация (но не значение) влияет на поведение объекта - тогда это всякие сервисы и по такой логике все, что имеет только значение - не является зависимостью

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

да, у меня с такими формулировками ещё не все хорошо

я за формулировками и пришел...

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

зависимость - это что-то, изменение чего может повлиять на поведение зависимой сущности (не entity, а класса - к примеру)

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

как скаляр (к примеру) может быть зависимостью?

скаляр является значением, данными, зависимость от данных это тоже зависимость.

зависимость, не отрицаю

тем более в случае передачи по ссылке

проблема в том, что в большинстве случаев (опустим фронтенд) это не отслеживается

если тебя интересует как связанность тут может проявляться.... ну вот тебе пример. Вот есть у тебя int. инт как инт. Че там может быть такого. Вот только инт этот в одной системе может быть 32-х битный а в другой 64-х битной а в третьей он 64х битный беззнаковый ровно до тех пор пока не появляется в левой части выражения с побитовыми операциями (привет js)

а еще веселье с big/little endian

ну это уже вопросы реализаций

и вот уже не все так просто

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

(зависимостей, ессно)

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

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

ну по такой формулировке вопрос Николая сразу решается

это могут быть данные, время, квантовые флуктуации.... что угодно

точнее не так... влияет не на поведение а на конечный результат

угу, согласен

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

сервисы - statless а значения это и есть state

ну это я так разницу воспринимаю

сервисы не всегда стейтлесс (к сожалению) хотя тут как приготовить

хотя сервисы могут ссылаться на значения...

и сущность (стейт) может иметь поведение

а я не говорил что значения не могут иметь поведения

я про поведение вообще не говорил....

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

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

а сервисы.... это даже не объекты... это модули скрывающие зависимости.... как правило.

набор функций, некоторые из которых имеют доступ к некому стэйту

надо услышать постановку проблемы

ERROR: S client not available

да, а то меня опять понесло чет

а то мы рассуждаем, а в чем фактически контекст - не видно

может там все прозаичнее

а то мы рассуждаем, а в чем фактически контекст - не видно

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

набор функций, некоторые из которых имеют доступ к некому стэйту

поведение сущности - тоже набор функций, имеющие доступ к некоторому (некоторый включает в себя весь) стейту :) чую DCI пробегал...

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

сущности и VO это еще ладно

а сервисы....

поведение сущности - тоже набор функций, имеющие доступ к некоторому (некоторый включает в себя весь) стейту :) чую DCI пробегал...

ну в рантайме то оно все так, таблица диспетчеризации и структурки

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

имхо серебряной пули нет даже если сервис стейтфул (коннект к базе etc) - стараюсь выносить этот стейт за контекст текущей операции

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

а если бы я был умным - я бы понял

но я нет и даже не уверен уже что шутки про монады тут в тему

trigger @mkusher

тогда уже Колю триггерить надо тоже

@Lividgreen

а пока ждем можем посмотреть смешные видосики

https://www.youtube.com/watch?v=I8LbkfSSR58&list=PLbgaMIhjbmEnaH_LTkxLI7FMa2HsnawM_

не, уже не сегодня я вот смотрю на if err != nil и чет думаю про монады Maybe

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

сори, отходил... кароч, мотивация какая: ччасто в DI-либах встречается это разграничение, на "параметры" и "зависимости" и хотя с одной стороны параметры - те же зависимости, но они выносятся отдельно и на то есть несколько причин

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

если мы говорим в контексте DI, то зависимости могут быть параметризованы. То есть.... мы можем описать зависимости и их параметры. И можем захотеть часть параметров вынести вовне, например, в параметры окружения. В этом смысле разделение корректно.

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

в линуксиках щас почту всё так же через sendmail шлют или чёт по дружелюбнее в плане конфигурации есть?

йоу, коллеги! странный вопрос в чате: все ли параметры конструктора можно считать "зависимостями"?

Объекту для работы нужны другие объекты и настройки. Скаляр - это как раз настройка. Так что это всё его зависимости.

сори, отходил... кароч, мотивация какая: ччасто в DI-либах встречается это разграничение, на "параметры" и "зависимости" и хотя с одной стороны параметры - те же зависимости, но они выносятся отдельно и на то есть несколько причин

Разграничение делают чтобы строковое значение параметра со строковым именем класса сервиса не перепутать.

Объекту для работы нужны другие объекты и настройки. Скаляр - это как раз настройка. Так что это всё его зависимости.

не соглашусь, скаляр - не обязательно настройка

Разграничение делают чтобы строковое значение параметра со строковым именем класса сервиса не перепутать.

это уже детали реализации