сделай коменты через гитхаб issue

Вот вы критикуете, а показать ничего своего не можете в пример

Вот вы критикуете, а показать ничего своего не можете в пример

накидай идей

что тебе показать, что рассказать)

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

хочу свежих идей для пет проджектов

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

вот вчера забыл спросить: чем тебя убер так возбудил?)

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

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

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

я смотрю ты решил в каждый онлайн магазин завозить по ооп? )

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

я смотрю ты решил в каждый онлайн магазин завозить по ооп? )

"эктор модел" - это нынче хайповая штука по идее)

обмажутся всякими akka-ми со скалами и чейнят друг друга

А если хотите полного драйва с блэкджеком и VO, то вам сюда: http://www.elisdn.ru/blog/104/domain-entities-modelling

public function getId(): EmployeeId { return $this->id; } ... $this->id = new EmployeeId( $this->getAttribute('employee_id') ); o_0

серьёзный подход

прям как выше с $item_id . $mod_id

что тебе показать, что рассказать)

Напиши интернет-магазин с ддд, чтоб все поняли как это - ддд Я вот не совсем пойму

Напиши интернет-магазин с ддд, чтоб все поняли как это - ддд Я вот не совсем пойму

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

ну то есть.... если дать посмотреть на проект где DDD и где это самое DDD оправдано - ты просто ничего не поймешь)

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

Сергей лучше бы ты примерами крыл

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

ты разбирался как работает UoW в ситуации когда ты коммитишь одну сущность?

Разбирался. Будет сохранён корень, его embeddables и все cascade-связи. Это вместе и есть агрегат.

я бы даже в избранное добавил

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

Ну вот. Это методология а не код. А то устроили срач на целые сутки из за Repository в имени класса. И какие-то "ошибки" якобы нашли.

Ну вот. Это методология а не код. А то устроили срач на целые сутки из за Repository в имени класса. И какие-то "ошибки" якобы нашли.

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

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

но люди потом просто приходят в твой гитхаб и офигивают

Разбирался. Будет сохранён корень, его embeddables и все cascade-связи. Это вместе и есть агрегат.

я не заметил что бы ты пояснял эти моменты в статье.

"эктор модел" - это нынче хайповая штука по идее)

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

ну и опять же, есть еще нюансы с one-to-many и еще - для того что бы это работало надо явно настраивать каскады.

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

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

серьёзный подход

Маппинг из полей БД в VO и обратно в обработчиках afterFind и beforeSave. В чём проблема?

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

Что сомнительного в использовании любой конкретной ORM кроме Doctrine или своего DM?

Что сомнительного в использовании любой конкретной ORM кроме Doctrine или своего DM?

я где-то форсил идею что "только DM спасет твою душу?"

если мы не гнушаемся делать кастыли вида $files = $this->files;$files[] = $file;$this->files[] = $files то сильно заморачиваться на тему чистоты нам не нужно. А это значит что и закрывать репозиторием AR нам не особо нужно.

и что помимо репозиториев есть другие подходы

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

это не особо сложно но зато намного проще в отладке

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

и что без этого неокрепшие умы могут и послать ибо "сложна"

но все же

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

но люди потом просто приходят в твой гитхаб и офигивают

Ну вот здесь пришли "диагональщики" в незнакомый им фреймворк и офигели с криком "ААААА! Что это??? Где DM!!! Persistance Ignorance нет значит не DDD!!!"

Ну вот здесь пришли "диагональщики" в незнакомый им фреймворк и офигели с криком "ААААА! Что это??? Где DM!!! Persistance Ignorance нет значит не DDD!!!"

ну для меня фреймворк более-менее знаком. И нет, я таких стремных вещей на нем не делал (делел другие вещи, возможно еще более стремные, но это было давно)

по поводу persistence ignorance - ты там что-то говорил про SOLID вообще-то

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

а если он его и соблюдает местами - то это solid ради solid без какого либо профита даже с точки зрения тестирования

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

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

Все сервисы соблюдают

Все сервисы соблюдают

а сущности и не должны)

p.s. сервисы не смотрел

А сущности в чём именно так критично его не соблюдают? Только S из-за неразбиения на контексты?

А сущности в чём именно так критично его не соблюдают? Только S из-за неразбиения на контексты?

ну не только из-за недоразбиения, персистенс

явная связанность с фреймворком была заменена менее явной но более жесткой связанностью

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

ERROR: S client not available

а в прочем...

можешь и не отвечать

Маппинг из полей БД в VO и обратно в обработчиках afterFind и beforeSave. В чём проблема?

я про class EntityId

я про class EntityId

ммм... это как раз таки норм)

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

а как было бы красиво... type UserID = string;

ммм... это как раз таки норм)

ну знаешь

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

где-то в параллельной нормальности

где-то в параллельной нормальности

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

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

и был класс его чекающий и вот это всё

ммм...

но uuid не нужны в нашей реляционно-объектной реальности

чем это отличается от string?)

да ничем

но uuid не нужны в нашей реляционно-объектной реальности

мде)

схема графкл

да ничем

то есть если нам нужен не просто uuid а именно uuid юзера нам всеравно придется фигачить UserID

я ни разу не видел проблем из-за айди )

даже намёков

я ни разу не видел проблем из-за айди )

с постгрессом - проблем нет. С мускулем - есть нюансы...

опа

имхо наоборот

но ты продолжай

с мускулем можно хранить юид в бинарном виде и всё ок

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

не так удобно, но в целом ок