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

По сути рекомендация сводится к минимизации кода, прямо использующего внутреннюю структуру объекта.

Всем привет, помогите прозреть. Есть легаси код, нужно как то грамотно переписать. Собственно интернет магазин, есть заказы, заказ по сути корневой агрегат, содержит в себе ряд других агрегатов, таких как клиент, адрес доставки, и еще по мелочи. Сейчас в общем выглядит так, фреймворк yii2: Прилетает запрос с данными, создаются несколько форм. создается новый класс, не знаю даже как его правильно назвать, принимает в конструкторе все эти формы у класса вызывается метод create - который готовит DTO для заказа потом вызывается save у него же, который через сервис создает entity и через репозиторий сохраняет 1. Собственно ряд вопросов, кто должен отвечать за dto для создания дочерних агрегатов, корневого? 2. Должен ли dto для корневого агрегата содержать сущности или же должен так же содержать dto для этих сущностей, которые в свою очередь будут созданы при создании сущности корневого. Может ли корневой агрегат внутри себя создавать дочерние? 3. Как это вообще грамотно организовать? Сильно не пинайте, хочется разобраться.

По сути рекомендация сводится к минимизации кода, прямо использующего внутреннюю структуру объекта.

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

Всем привет, помогите прозреть. Есть легаси код, нужно как то грамотно переписать. Собственно интернет магазин, есть заказы, заказ по сути корневой агрегат, содержит в себе ряд других агрегатов, таких как клиент, адрес доставки, и еще по мелочи. Сейчас в общем выглядит так, фреймворк yii2: Прилетает запрос с данными, создаются несколько форм. создается новый класс, не знаю даже как его правильно назвать, принимает в конструкторе все эти формы у класса вызывается метод create - который готовит DTO для заказа потом вызывается save у него же, который через сервис создает entity и через репозиторий сохраняет 1. Собственно ряд вопросов, кто должен отвечать за dto для создания дочерних агрегатов, корневого? 2. Должен ли dto для корневого агрегата содержать сущности или же должен так же содержать dto для этих сущностей, которые в свою очередь будут созданы при создании сущности корневого. Может ли корневой агрегат внутри себя создавать дочерние? 3. Как это вообще грамотно организовать? Сильно не пинайте, хочется разобраться.

1. что значит создаются несколько форм? Валидаторы какие-то 2. что значит создается класс, может объект создается? 3. что значит у класса метод вызывается, методы же у объектов О.о 4. агрегат в себе не может содержать другие агрегаты, только хранить ссылки(id в идеале) на другие. Агрегат это граница бизнес транзакции, т.е. в одну транзакцию вовлечен(меняется) один агрегат 5. зачем класс создает dto, entity, вызывает save, идет в репозиторий и чето еще сохраняет? Это какой-то мрак 6. зачем вам вообще dto? DTO не содержит в себе других сущностей, ведь они не transfer objects(обычно)

1. что значит создаются несколько форм? Валидаторы какие-то 2. что значит создается класс, может объект создается? 3. что значит у класса метод вызывается, методы же у объектов О.о 4. агрегат в себе не может содержать другие агрегаты, только хранить ссылки(id в идеале) на другие. Агрегат это граница бизнес транзакции, т.е. в одну транзакцию вовлечен(меняется) один агрегат 5. зачем класс создает dto, entity, вызывает save, идет в репозиторий и чето еще сохраняет? Это какой-то мрак 6. зачем вам вообще dto? DTO не содержит в себе других сущностей, ведь они не transfer objects(обычно)

1. Ну по сути да, только для валидации. 2. Да, объект, прошу прощения) 3. Та же беда. 4. Ну вероятнее я не совсем корректно использую терминологию. Пример такой, есть заказ у которого есть адрес доставки, но адрес доставки это другая сущность, которая не имеет смысла без заказа, но может быть изменена. Является ли адрес доставки агрегатом? 5. Еще какой мрак, поэтому и переписывается. 6. на основе dto создаются сущности. только наверное для этого и используются

То есть есть агрегат, который содержит в себе сущности, вот так пожалуй правильно будет.

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

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

а что если корень агрегата вызывается/создается прямо из контроллера?)

ну как вариант

Здравствуйте уважаемые ооп разработчики

Исполльзуете ли вы суффикс Listener для листенеров?

а он точно листенер?

может главная задача твоего объекта какая-то другая?

всм суффикс, а чего не постфикс?

может главная задача твоего объекта какая-то другая?

вот да, собственно с этой мысли и возник вопрос)

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

Исполльзуете ли вы суффикс Listener для листенеров?

Это относиться ко всем паттернам: Мне понравился ответ, что если это повышает читабельность и понимание кода - то стоит, если overhead - то нет.

вот есть событие показа витрины, я пишу сервис /слушатель который запишет статистику в кликхаус

ShowcaseAbTestStatWriter

пока так назвал

ну типо а то что это слушатель будет ясно по наличию метода onShowcaseWasShown и тайпхинту

всм суффикс, а чего не постфикс?

некоторые проблемы с морфологией

а почему не как то так ? class ClickHouseStatUpdater __invoke(ShowcaseShownEvent event) примерно

Дык может а этот кликхаус 100500 событий летит

Из разных листенеров

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

единствоответственности все дела

а почему не как то так ? class ClickHouseStatUpdater __invoke(ShowcaseShownEvent event) примерно

не совсем понял что тут делается

Дык может а этот кликхаус 100500 событий летит

да так и есть

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

а щас переделывается на события

каждый класс слушатель просто на входе получает евент нужного типа

например будут классы ClickHouseShowcaseOpenUpdater, ClickHouserShowcaseCloseUpdater и тд

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

Updater и Listener разницы немного

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

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

я не понял зачем через invoke это делать

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

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

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

грубо говоря есть событие есть обработчики (один или несколько или неодно, описано в конфиге)

чето я мысль вообще потерял

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

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

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

вот

эт событие просто в бас кидается и обработчики никак не связаны между собой

у тебя есть цепочка обработчиков этого события

каждый обрабочтик это отдельный класс

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

Извините за оффтоп, а у вас много на работе коллеги матерятся?

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

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

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

Он не пишет тесты

Он не пишет тесты

я не пишу тесты и не матерюсь чяднт?

пиши тесты и матерись

еще раз у тебя есть vo с данными евента, на каждый евент свой тип например ShowcaseOpenEvent далее есть интерфейс обработчиков ShowCaseOpenListenerInterface далее есть непосредственно обработчики: ClickHouseStatUpdater implements ShowCaseOpenListenerInterface UserBan implements ShowCaseOpenListenerInterface и тд и есть место конфигурации что при событие ShowcaseOpenEvent нужно запустить следующие обработчики [ClickHouseStatUpdater::class, UserBan::class] (эта штука настрайвается как раз) и соответственно есть обработчик эвентов который на входе получает event опеределяет конфигурации и по тем классам его передает по крайне мере я как то так вижу обработчик эвентов

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

пиши тесты и матерись

справедливо

я не пишу тесты и не матерюсь чяднт?

Хуяк-хуяк и в продакшн?)

Хуяк-хуяк и в продакшн?)

да ಠ╭╮ಠ

еще раз у тебя есть vo с данными евента - ну это дтошка а не во далее есть интерфейс обработчиков нет нету, это вообещ не понимаю зачем может быть нужно То что ты описал вообще на какой то Chain of responsibility У меня просто обычные реакции на событие, котоыре вообще асинхронными могут быть и в теории не в этом запрсое выполнятся

еще раз у тебя есть vo с данными евента - ну это дтошка а не во далее есть интерфейс обработчиков нет нету, это вообещ не понимаю зачем может быть нужно То что ты описал вообще на какой то Chain of responsibility У меня просто обычные реакции на событие, котоыре вообще асинхронными могут быть и в теории не в этом запрсое выполнятся

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

нет всё не так

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

Просто этим он вводит в тильт всю команду)

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

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

и сделай также

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

да, и я выношу из менеджера методы

он вообще не на листенерах

это просто сахарок, который sql формирует грубо говоря

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

он ничего не слушает а просто дергается

чтобы класс делал только это (единство ответственности)

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

это и так понятно

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

ShowcaseAbTestStatWriter

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

что за AbTest и тд)

куда он пишет и тд

Привет. Кто-нибудь может объяснить некоторые особенности цикла событий (event loop)?

Привет. Кто-нибудь может объяснить некоторые особенности цикла событий (event loop)?

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

что за AbTest и тд)

ShowcaseAbTest - аб тест витрины. ПОлностью вот так звучит DemandsElasticityShowcaseAbTest куда пишет знать и не надо, так как это application и писать он будет туда, какой whiter заинджектим в него

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

Меня интересует вот что. События из цикла исполняются последовательно?

Меня интересует вот что. События из цикла исполняются последовательно?

нет. т.е. это зависит от имплементации

нет. т.е. это зависит от имплементации

Где можно узнать об этом?

В документации той реализации которую ты используешь.

ShowcaseAbTest - аб тест витрины. ПОлностью вот так звучит DemandsElasticityShowcaseAbTest куда пишет знать и не надо, так как это application и писать он будет туда, какой whiter заинджектим в него

получается у вас есть класс по работе с clickhouse есть adapter для вашего WriteInterface и есть абстрактный класс который берет данные из event и передает их WriteInterface я же предпологал чуть другое есть непосредственно обработчик события который знает какое событие и куда он пишет, для этого ему инжектят класс(client) по работе с кликхаусом ну ок вам видней как вам лучше

В документации той реализации которую ты используешь.

В контексте JS

Браузерного

Chrome, например

В контексте JS

https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop