сервисный слой, получающий команды и делегирующий сущностям

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

без него печально - порты/адаптеры становятся мечтой

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

просто где можно поместить логику которая относится к сущностям - в сущности, и уже код станет получше

вот, плюсую

в любом случае без сервисов никак

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

сервисы будут, будут еще DTO, целые модули будут, куча инфраструктурного кода и даже всякие хеплеры

ну или например сгенерировать какой то статус по закрытым issue

профакапили месяц или нет)

но возможно есть сущность Sprint и это в нее зайдет)

http://blog.byndyu.ru/2010/05/domain-driven-design.html короче почитай немного Бындю, там все описано

Меня один вопрос сильно смущает. Есть ли жизнь этих доменов без орм, которая той же рефлексией соберёт тебе объект, минуя корструктор. Ибо иначе, тебе придётся его руками создать и "провести" до нужного статуса

Я понимаю, что лень печатать, но вот у меня, например, возможности узнать содержимое войс-месседжа сейчас нет

И то, что есть стореджи/репозитории, отвечающие за маленькие части одного "агрегата". Они, в теории могут ходить в разные совсем датасеты. Чтобы его раз собрать, нужно композировать их сверху. А если ещё критерий выборки по типу аля джоин будет, то композиция эта ещё накладывает сложности

Я понимаю, что лень печатать, но вот у меня, например, возможности узнать содержимое войс-месседжа сейчас нет

Прости

Много буков

И с телефона вообще не удобно

Это со стороны. Вопрос в воздух

да оставьте на стрим обсуждение)

хотя бы цельный материал будет

да оставьте на стрим обсуждение)

Там обсудим дополнительно

Придумайте как стримить 2 монитора в ютьюб с федоры

И то, что есть стореджи/репозитории, отвечающие за маленькие части одного "агрегата". Они, в теории могут ходить в разные совсем датасеты. Чтобы его раз собрать, нужно композировать их сверху. А если ещё критерий выборки по типу аля джоин будет, то композиция эта ещё накладывает сложности

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

все зависит от проекта и самого домена у меня есть проект, где тонна инфраструктурного кода, при этом нет ни сущностей, ничего. и там мне не нужно это все, где надо делаются запросы к базам, достаются данные и дальше уже с ними колбасится инфраструктурный код а если этот проект сильно завязан на бизнес логику, т.е реальную бизнес логику, а не какие-то там круды. т.е это нужно работать со стейтом, стейт машинами, правилами, по типу икоммерсов, всяких страховых и прочих бухгалтерских систем. то там без нормального доменного дизайна ты далеко не уедешь и можно быстро погрязнуть в этих сервисах и хелперах, которые разростутся до 40++ методов и будут делать все на свете другая проблема что если у вас обычный круд, то начинают выдумывать и отказываться от структур данных в пользу rich model, хотя это реальный оверинженеринг в общем это все описано и у Фаулера, и у Эванса в книжках. если это пересказывать то выйдет много текста)

а @fes0r тактично слился

а @fes0r тактично слился

он решил не слушать)

офтоп кто-нибудь настраивал в aws для ec2 через load balanse ssl из ACM? не могу никак разобраться на сервере какие настройки сделать

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

Придумайте как стримить 2 монитора в ютьюб с федоры

youtube live + hangouts?

а @fes0r тактично слился

лень слушать было) остановился на странной трактокве information hiding)

Меня один вопрос сильно смущает. Есть ли жизнь этих доменов без орм, которая той же рефлексией соберёт тебе объект, минуя корструктор. Ибо иначе, тебе придётся его руками создать и "провести" до нужного статуса

И да и нет. По сути вопрос воспроизведения жизненного цикла сущностей. У тебя ЯП дает вполне четкий цикл жизни объекта. Начало (конструктор) и все остальное. В случае если делать без рефлексии - тебе надо как-то вопрос "вызываем один раз в начале жизненного цикла" как-то переместить куда-то. Это можно но зачем... То есть можно без ORM но без рефлексии неудобно.

ну и по поводу вечной войны инфраструктуры и домена - представим себе сервис букинга. Если в рамках одного какого-то помещения работа с расписанием красиво и вполне эффективно ложится на модель, то если вам надо искать среди десятков тысяч объектов, да еще и как-то по хитрому, то тут инфраструктурные ограничения побеждают и ты начинаешь размазывать логику по SQL. И сделать тут ничего особо нельзя.

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

СТРИМ))

во сколько? в какой день?

или пока в подвешеном состоянии все?

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

Но это из разряда фантастики?

во сколько? в какой день?

на след неделе решим

Но это из разряда фантастики?

почему же? просто это "немного не то"

на след неделе решим

понял, спасибо!

почему же? просто это "немного не то"

Переизобретение джоинов. Пробовал.

Переизобретение джоинов. Пробовал.

почему переизобретение?)

ну то есть можно и с джойнами - вопрос насколько удобно композицией запросы такие строить)

почему переизобретение?)

Ну когда ты их кодом пишешь, т. к. не знаешь, куда идти за первым типом сущности, а куда за вторым. И остаётся только кодом скрещивать. Или изобретать dql

Актуально для коллекций. В свете вчерашних обсуждений, пускай будут issue со своими подзадачами

Переизобретение джоинов. Пробовал.

но все же - не понравилось? мне вот понравилось) Правда не надо в крайности - у меня например на один метод API есть жирная выборка, части которой имеют свои джойны и юзаются в других местах. Но вот для этой штуки сильно усложняется гидрация и логика самих запросов. А так вжух, 3 выборки, каждая с 3-мя джойнами, склеил выплюнул. Удобно. По производительности не сказать что плохо. Да и доктрине с гидрацией проще)

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

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

я б тебе советовал как-то упрощать пояснение и опускаться поближе к реальности)

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

я б тебе советовал как-то упрощать пояснение и опускаться поближе к реальности)

что есть "ближе к реальности"? тип как все привыкли?

просто тот кусок был похож на мысли вслух)

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

и это тип говорит о том что "вертикальное разделение приложение миф"?

или больше говорит о том что большинство не парятся?

ERROR: S client not available

что есть "ближе к реальности"? тип как все привыкли?

тут для людей инкапсуляция это "нуу, у меня ж в сервисе скрыта логика, вот инкапсуляция"

а ты за контексты топишь)

не топлю, там троеточее в конце))

я привел конкретный пример когда "ну не выйдет сделать красиво в модели логику и придется размазать по SQL"

Это у Эванса все клево и красиво в книжке, а в реальности инфраструктура часто побеждает над чистотой модели

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

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

разумеется)

ребяты я еще раз закину свой вопрос для domain events дергать releaseEvents в сервисном слое это вообще типа ок?

я сколько не гуглил мнения людей которые искали пути уменьшения связанности, большинство в своих размышлениях приходят к whole value. А после для таких случаях к event driven подходам

ребяты я еще раз закину свой вопрос для domain events дергать releaseEvents в сервисном слое это вообще типа ок?

да, почему нет

мне это просто слегка калечным кажется совсем не магическое)

хотя ,наверное, это самый правильный вариант

мне это просто слегка калечным кажется совсем не магическое)

может быть я не правильно тебя понял?

да и в том же litecqrs и подобных это реализовано подобным образом (речь не про cqrs, а про примеры реализации)

в целом releaseEvents должен вызываться там где ты уже знаешь что эти ивенты... факты. То есть данные сохранены, транзакция закоммичена и все такое

я имею ввиду то, что мне не нравится необходимость дергать releaseEvents и dispatch вручную

а где у тебя это место - сам решай)

я имею ввиду то, что мне не нравится необходимость дергать releaseEvents и dispatch вручную

что значит "вручную"?

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

значит, что вручную прописать)

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

ну у меня нет такого) или ты про flusher свой?

ну у меня нет такого) или ты про flusher свой?

ну если у тебя только доктрина - достаточно postFlush листенера. У меня не только доктрина потому своя надстройка

смотри, как было в litecqrs во всех хендлерах был встроен сервис identitymap и в хендлерах я дергал $this->map->add($entity); да, это вручную, но на одну строчку кода меньше :D а дальше уже сама шина выдергивала все сущности из identitymap и раскидывала их ивенты в диспетчер

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

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

смотри, как было в litecqrs во всех хендлерах был встроен сервис identitymap и в хендлерах я дергал $this->map->add($entity); да, это вручную, но на одну строчку кода меньше :D а дальше уже сама шина выдергивала все сущности из identitymap и раскидывала их ивенты в диспетчер

оч странная штука

оч странная штука

да не отрицаю

да не отрицаю

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

я правильно понимаю, что список доступных локалей с переводами надо как-то самому задавать? (т.е. нет способа из коробки получить локали, для которых есть переводы)

я правильно понимаю, что список доступных локалей с переводами надо как-то самому задавать? (т.е. нет способа из коробки получить локали, для которых есть переводы)

башем можно вычленить) поиском по файлам)

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

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

а у меня вариант именно такой