ну и еще там есть всякие рейтинги юзеров в этом компоненте

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

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

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

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

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

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

связь между контекстами

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

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

Зависит от алгоритмов)

?

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

че надо то?

пастух люцифера

Какой варик быстрее: заполнять бинарное дерево до полного пустыми значениями и юзать одномерный массив для хранения, или юзать неполное бинарное дерево, но заполнять двумерный массив?

Какой варик быстрее: заполнять бинарное дерево до полного пустыми значениями и юзать одномерный массив для хранения, или юзать неполное бинарное дерево, но заполнять двумерный массив?

а цель то какая?

цель - выбрать наиболее быстрый вариант D:

окей, дерево зачем тебе?

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

в этом же смысла нет

Есть, можно юзать одномерный массив для хранения

Есть, можно юзать одномерный массив для хранения

ну тогда тебе дерево не нужно)

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

ну тогда тебе дерево не нужно)

нужно нужно

цель - выбрать наиболее быстрый вариант D:

какие операции длжны быть быстрыми?

да, вопрос выше правильный

поиск например

поиск числа в дереве?

пирамида?

красно-черное?

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

поиск например

поиск разный бывает. И на выбор алгоритмов и структур влияет характер данных и поиска.

да

Если только поиск то подумай о хеш таблицах еще.

Дайте-ка я побрежу. Есть набор моделей, например Author, Topic, Comment etc. Они могут быть в отношениях, довольно сложных, например Comment отновится к определенному Topic, и у него есть Author. Конструкции типа comment.getTopics[0].getAuthor.getFolowers понятно нарушают LOD. Может быть тогда вообще сделать так, чтобы сущности не знали друг про друга? У Comment не будет методов вроде getTopic() или getAuthor().

А информация о связях, например, будет храниться отдельно. как-то. Не знаю, как.

может тебе не надо просто гидрировать данные на сущность?)

ну то есть.... что ты сделать хочешь? Подготовить данные для UI?

а как надо?

ну да

ну сделай выборку, жазни все в ArrayHydrator какой

и радуйся

не надо париться о LOD)

не надо париться с геттерами

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

ну так, идеальный кейс для такой штуки как SQL)

ну сделай выборку, жазни все в ArrayHydrator какой

есть пример этого?

ну просто через query builder выбираешь те данные которые тебе нужны

получается у меня DB mapper будет возвращать некий сложный массив?

и говоришь ему в getResult что бы не ObjectHydrator юзало а ArrayHydrator

и этот массив отправится прямо во вью?

ну тип того

еще ты можешь в select писать штуки вроде select new MyViewDTO(author.id)

но я этим пока не пользовался особо(

насколько я понял такое работает хорошо для простых данных

но это если ты хочешь загоняться

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

эдакий прототип

прототип у меня уже работает

щас фаза рефакторинга

ну я хз... было б неплохо выслушать других людей

ERROR: S client not available

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

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

чуть более в сторону вопрос: зачем вообще моделям знать о своих связях?

зачем Comment знать о своем Author?

что бы построить агрегат сущностей

public function comment(string $message, User $author) { $this->comments->add(new Comment($message, $author); }

ну то есть без связей такое сделать не получится особо

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

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

if ($this->comments->matching(Comment::byAuthorCriteria($author)) { throw new MultimpleCommentsNotAllowed($author, $topic)l }

а почему агрегат не может знать о связях? ну типа $comenter = new PostCommenter($post); $commenter->comment($text, $date)

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

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

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

их сущности Topic по коллекции комментов по отдельной критерии

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

односторонюю

не?

смотрю, не понимаю, почему это же самое не реализовать в PostCommenter

а почему агрегат не может знать о связях? ну типа $comenter = new PostCommenter($post); $commenter->comment($text, $date)

агрегат - это граф и у него есть корень

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

смотрю, не понимаю, почему это же самое не реализовать в PostCommenter

ну потому что... тогда зачем тебе доктрина и сущности вообще?) юзал бы dao какой-нибудь

а у меня и нет доктрины

а сущности тогда откуда?

ну это модели

просто модели типа Comment

"модели" - это очень абстрактное слово

модель данных типа?

ну тогда она будет просто повторять твою базу данных