если слышал есть такое понетия - стоимость перевода. Это мол когда ты переводишь что-то во что-то смысл теряется немного

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

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

ему тут даже DTO не нужны, не говоря уже о промежуточном мэппинга не сущности

ладно, вернусь домой и пообщаемся на эту тему

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

ладно, вернусь домой и пообщаемся на эту тему

)

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

короч самая главная штука в DDD - единый язык

эт тоже было)

но это все тоже лирика имхо )

не, это на самом деле важно особенно на проектах где сложный домен

кароч надо перечитать ддд книги )

вновь

или не сложный, но какой-то специфичный

просто у большинства DDD ассоциируется тупо со слоеными архитектурами. Что не есть правда

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

а то у меня дальше просмотра лекции не пошло

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

ну было немного, сча меньше

а то у меня дальше просмотра лекции не пошло

ну тип идея простая. У тебя есть слои, в частности внутри у тебя приложенька а снаружи инфраструктура. Ну и все это между собой связано через инверсию зависимостей (порты на стороне слоя приложеньки и адаптеры к этим портам в слое инфраструктуры)

профит - ты можешь крутить и вертеть инфраструктурой как хочешь

ну было немного, сча меньше

сча меньше почему?

Зачем так много умных слов?(

сча меньше почему?

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

ну то есть там по мелочи

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

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

Всем привет, я уже как-то спрашивал, но походу суть не уловил. Объясните правильный подход к flush в доктрине. В какой момент грамотно делать flush. Вот например есть репозиторий с юзерами, там метод add. В нем делать только persist? или persist и flush?

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

почему?

ну персист еще ладно

но в идеале флаш должен быть один перед отдачей респонза

хотя подходы у всех разные, некоторые любят флашть после персиста я сторонник флаша в контроллере перед return

флаш нужно делать чем раньше тем лучше, т.к как только закончилась бизнес транзакция

а не собирать все в кучу

persist в репе норм

у вас ж стопро есть методы аля public function add

но в идеале флаш должен быть один перед отдачей респонза

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

уже были набросы на эту тему, даже окрамиус сказал persist/flush внутри метода репоса эт ок

я так понимаю добавить пользователя это бизнес транзакция?)

уже были набросы на эту тему, даже окрамиус сказал persist/flush внутри метода репоса эт ок

вот только они хотят заменить это предоставив метод save

да, вполне

без UoW

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

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

RegisterUserHandler например

чем раньше ты закроешь транзакцию, тем лучше

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

чем раньше ты закроешь транзакцию, тем лучше

ну так до flush ты ее и не открывал)

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

ну тогда надо писать не на php)

RegisterUserHandler внутри собирает только то что касается регистрации юзера верно? Может ли быть внутри еще бизнес транзакция?

принимание реквеста, его обработка и сохранение в базу - это одна транзакция

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

принимание реквеста, его обработка и сохранение в базу - это одна транзакция

не всегда)

иногда это больше одной бизнес транзакции

не путаю это простой бизнес-кейс принять данные из реквеста, их обработать и сохранить

больше одной - это если надо разослать мыло с подтверждением например

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

не путаю это простой бизнес-кейс принять данные из реквеста, их обработать и сохранить

юз-кейс

больше одной - это если надо разослать мыло с подтверждением например

нет, это как раз входит в юз-кейс регистрации юзера

а несколько юз-кейсов за один запрос, это например импорт товаров

а доктрина , что на 5 персистов и 1 флаш все равно шлет 5 запросов ,А не 1 балк инсерт к примеру?

да, 5 запросов

а доктрина , что на 5 персистов и 1 флаш все равно шлет 5 запросов ,А не 1 балк инсерт к примеру?

doctrine/dbal не умеет bulk insert

потому что bulk insert не умеют все СУБД которые хочет поддерживать доктрина

https://github.com/stas29a/doctrine2

кто-то пробовал?

https://github.com/stas29a/doctrine2

он тут свой persister добавил и все

кто-то пробовал?

чет не хочется юзать форк доктрины для решения одной маленькой проблемки

ERROR: S client not available

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

кстати, а он делал реквест в доктрину? что они сказали?

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

очень грустна(

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

расширять это добро боль

и твой пулреквест никто не примет)

ну я как бы пока и не собираюсь

и твой пулреквест никто не примет)

а почему?

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

а почему?

потому что: - у них фича фриз, они хоть завтра могут выпустить доктрину 2.6 и на этом конец ветке 2x - у них только один чувак сейчас активно ее поддерживает. и то последние 2 месяца у него небыло времени - ближайшее время переписывается система метаданных доктрины, от слова полностью. И на этом завязано почти все, а потому пока это не будет сделано распаралелить разработку над третьей версией нельзя. Ну и как реультат - пока нечем помочь

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

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

потому я юзаю свой форк доктрины)

воу)

можно помочь краудфандингом

например)

оплачивать разработку доктрины

я бы сотку кидал каждый месяц

лишь бы побыстрее пилили

p.s. интересный факт - из доктрины 3 выпилены embeddable) ну потому что во 2-ой версии они были сделаны кастылями а в третьей потом сделают нормально

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

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

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

да на гидраторах можно много чего делать

сделал так что бы ArrayHydrator сохранял структуру объектов

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

но пока оч плохо тещено

а вообще у меня была безумная идея (но это я только в Мае буду пробовать) - сделать сбоку от доктрины систему вьюшек

ну мол какие-то проекции сущностей

по сути своя реализация DQL

с кодогенерацией и все такое