первое - для твоего агрегата, второе - для операций которые вовлекают несколько агрегатов из разных контекстов

(по сути процесс)

Про агрегаты надо курить сильно. А то я пока додумался только до того, что агрегатов у меня чуть ли не всего два-три, но что делать с остальной сотней структур я, как старый дбшник, ума не приложу. Придётся почитать Вернона повнимательнее и порисовать на бумажках.

Ивенты сейчас использую вообще не из aggregate root, а из хэндлеров команд (юз-кейсов), они больше знают о контексте. И по сути, ивенты — механизм декаплинга подсистем.

Ивенты сейчас использую вообще не из aggregate root, а из хэндлеров команд (юз-кейсов), они больше знают о контексте. И по сути, ивенты — механизм декаплинга подсистем.

это просто ивенты, доменные ивенты концепт чуть интереснее

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

вообще по поводу майнд шифта

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

ну то есть раньше я как делал - есть скажем продукт. Это одна какая-то структура данных которая хранит все что связано с этим продуктом. Стоимость, описание, кто продает и т.д.

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

то есть ProductPrice, ProductAvailability, ProductDetails, Configuration и т.д.

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

VO?

VO?

нет, именно сущности

внутри могут быть VO

да, сорри, чуть мимо неиммутабельные VO получаются :D но это оффтопик, сейчас мне интнереснее почитать

да, сорри, чуть мимо неиммутабельные VO получаются :D но это оффтопик, сейчас мне интнереснее почитать

у них есть идентификатор потому это полноценные сущности

идея в том что это все "продукт" в разных контекстах

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

в контексте резервации товаров, в контексте продукт плэйсмента, в контексте формирования цены и т.д.

идея в том что это все "продукт" в разных контекстах

угу, тут вспоминаю о микросервисах от уди

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

а на уровне кода как это организовать?

embeddable?

классы, файлы)) как еще?)

не совсем то

доктрина

нет, полноценные сущности

разные таблички

uuid спасет, да... хм.

вообще полностью разрезано все

да, и все на uuid, но можно и на секвенсах - просто будет одна последовательность для всех табличек

да, тут первая мысль отношения one to one

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

да, тут первая мысль отношения one to one

им не нужны отношения)

им не нужны отношения)

да вижу) это закостенелый ум чуть

привычка - страшная сила

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

в первом приближении не сильно сложнее того, что умеешь)

что-то во всём этом определённо есть.

в первом приближении не сильно сложнее того, что умеешь)

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

да вижу) это закостенелый ум чуть

под доктрину у меня в драфте статья лежит, надо определиться куда запостить)

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

самое время начать)

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

самое время начать)

все по порядку, сначала продвинуться в верноне дальше первых 40 страниц

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

у меня были кастыли с batch загрузкой, потому на довольно сложный граф объектов + списочки + еще всякие штуки уходило где-то 5-6 запросов

и в целом весьма удобненько

просто много where in запросов

+ удобно делать кэширование)

а треть всех сущностей вообще выходили read only

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

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

ну вот у меня 5-6 было на список заказов

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

кеширование да, но его тоже на практике не делал, потому плаваю в теме

ну было бы 10 запросов

мега примитивных

where in разве примитивные?

кеширование да, но его тоже на практике не делал, потому плаваю в теме

кэширование read only данных - легко и просто, а вот когда доходит до инвалидации кэша - все очень непросто

насколько помню, они довольно весомые

насколько помню, они довольно весомые

по PK

с чего бы им быть тяжелыми?

короч меня 10 запросов на "достать список заказов" более чем устраивает)

кэширование read only данных - легко и просто, а вот когда доходит до инвалидации кэша - все очень непросто

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

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

сказка с мускуля древней версии.

кэширование read only данных - легко и просто, а вот когда доходит до инвалидации кэша - все очень непросто

то, что кеш - это просто - само собой понятно просто пока не пощупал - определенное "плавание" в теме остается

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

да, вполне

ERROR: S client not available

по PK - ну да, индексы, это не по контент полям все же

короч меня 10 запросов на "достать список заказов" более чем устраивает)

ну вполне. Когда перестанет устраивать, всегда можно маппер одного запроса нафигачить.

да, мэппер запросов в DTO, вьюшки, кэш

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

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

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

никак

чистые запросы?

с вьюшками через SQL работай типа

да, это не так страшно как ты думаешь

ээ, почему через SQL? С точки зрения любого ORM пофигу абсолютно.

ибо пофигу даже с точки зрения селекта

ээ, почему через SQL? С точки зрения любого ORM пофигу абсолютно.

в php есть одна вменяемая ORM - Doctrine, и она не умеет работать с вьюшками. Но если ты работаешь не с сущностями - то ей пофиг

если вы про вьюшки дб

ибо пофигу даже с точки зрения селекта

ORM не пофиг на мэппинг/гидрацию

та ORM о которой мы говорим заточена под write операции, там встроенный UoW, Data mapper и все такое.

на read они предлагают юзать sql + dto

хм, на выходных почитаю. Доктрину я так по большому счёту не использовал в бою. Под капотом у меня обычно оракл или постгре.

у них там свой маппер есть на дто? или самому писать?

хм, на выходных почитаю. Доктрину я так по большому счёту не использовал в бою. Под капотом у меня обычно оракл или постгре.

доктрина ведь не против оракла и постгри)

насчет оракла не уверен правда

у них там свой маппер есть на дто? или самому писать?

ну типа SELECT new SomeDTO(u.id, u.email);

dql?

насчет оракла не уверен правда

мы делали проект на оракле с доктриной

блин, где-то на днях такую штуку видел

dql?

или query builder - это не столь важно

тогда вот ей не пофиг, что во FROM стоит?..

тогда вот ей не пофиг, что во FROM стоит?..

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

НО! ты можешь мэппинг подсунуть под любой запрос, просто это больше работы

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

PDO::FETCH_CLASS , как вариант

PDO::FETCH_CLASS , как вариант

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

а что если тебе надо иерархию какую?)