Хмм... надо на каком то знакомом примере... сейчас попробую накидать что-то

Скажем у нас есть теже профили пользователей. Бизнес обеими руками за то чтобы иметь полную историю изменений пользователя и мы такие окей, самое время для ES. И тут нам озвучивают бизнес правило что E-Mail может быть одинаковым между максимум 3 пользователями (тупой пример, да). Как такое рулить на реально больших данных. Когда мы не сможем сделать какой-то явный EmailIndex и поднимать его в память...

Сумбурно как-то получилось

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

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

А? что? где?

мы со Стёпой отказались от идеи всё в память грузить, так что наступило щасце

Скажем у нас есть теже профили пользователей. Бизнес обеими руками за то чтобы иметь полную историю изменений пользователя и мы такие окей, самое время для ES. И тут нам озвучивают бизнес правило что E-Mail может быть одинаковым между максимум 3 пользователями (тупой пример, да). Как такое рулить на реально больших данных. Когда мы не сможем сделать какой-то явный EmailIndex и поднимать его в память...

а рид модельку ты не можешь для этого юзать?

вродеж ничего плохого в том что write модель юзает внутри проекции какие-то свои нету

Могу. Вопрос согласованности.

А? что? где?

в общем у нас индекс - отдельный сторадж (база, табличка, etc) key/value

можно prefix-tree замутить, нет? выйдет быстрый маленький индекс

или фильтр блума

Как вариант. Вообщем вопрос не о деталях реализации. А о том как жить когда в агрегате надо хранить ну очень много ивентов. Точнее даже не так. А как проектировать агрегаты так чтобы в них такого не случалось.

много - эт сколько?

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

Больше чем поднимает память :)

Дело не гидрации, снапшоты не помогут

почему?

Ну вот смотри начали мы проектить системы и намутили агрегат Catalog. И будут у нас там лежать товары. И вроде все пока хорошо. Но потом оказывается что товаров будет много и нам чтобы востановить состояние агрегата Catalog надо ну очень много памяти. Да у нас есть снапшоты которые позволяют ускорить гидрацию. Но уже после нее агрегат Catalog таки занимает дочерта в памяти. Очевидно что систему мы спроектировали неправильно и агрегатом должно быть что-то другое. Очевидный вариант - Товар, но правильно ли это?

Тут приходят контексты на помощь конечно

Вообщем не могу я правильно это сформулировать... Надо вживую обсуждать.

я всё равно не понял почему при наличии снепшотов у тебя уходит много памяти(

Потому что сам снапшот большой

а ты в нём хранишь список всех событий с их пейлодом?

Нет конечно, сериализованный агрегат в какой-то там версии близкой к правде.

ну с чего ради он тогда большой, если ты просто стейт агрегата сериализовал?

С того что в стейте дофига всего напихано...

И что конечно заранее мы такого не предполагали но на определенный момент так вышло

С того что в стейте дофига всего напихано...

а дофига это сколько? 100 гигов? 200? 500?

Что думаете по поводу

https://codengineering.ru/post/45

https://github.com/stomp-php/stomp-php

"Обычно событием является запрос какой-то информации" т - терминология

как должно выглядеть событие, которое запрашивает результат?)

в целом, так и не понятно, о чём статья) то ли с amqp работать учат, то ли pub/sub показывают...

Ненавижу ООП

Ненавижу ООП

Именно поэтому вы тут?

Именно поэтому вы тут?

Да

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

Ненавижу ООП

Это ты взломал сервер господень?

Это ты взломал сервер господень?

Ох уж эти кошмары...

Хммм... А кто - нибудь тусил на старом форуме фильма }{oTT@Бb)4 ?

Ненавижу ООП

++

Ненавижу ООП

плюс)0

Ненавижу ООП

вы хотите об этом поговорить?

ненавижу гаечные ключи

Ненавижу ненавидеть ненависть

ERROR: S client not available

А я томат...

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

Здравствуйте. если у меня есть класс, в котором 3 поля (свойства) являются ValueObject. Можно ли считать этот класс агрегатом?

да

ты же агрегируешь в нем объекты

спасибо

вопрос в том, агрегат это или агрегатор)

О! и тут привет

Здравствуйте. если у меня есть класс, в котором 3 поля (свойства) являются ValueObject. Можно ли считать этот класс агрегатом?

если этот объект представляет собой границу бизнес транзакции (операции) - то да.

ну то есть плевать что внутри твоей сущности - агрегат это про бизнес операции и все вовлеченные части

Сидел тут думал думал короче. И пришел к выводу что нормально спроектированное приложение по всем канонам ооп в пхп просто обречено на провал. И все из-за жизненного цикла приложухи. Короче с каждым запросом как птица феникс возрождается и потом снова умирает. Мало того что язык с большушим таким оверхедом сам по себе, так еще и это вот все жрет ресурс как не в себя Взять к примеру Syllius да. Все там вроде очень красиво выглядит, Но сцук когда открываешь магазины, на нем реализованные и видишь отдачу хтмлки в 2-3 секунды... это очень удручает. Оно в принципе не способно конкурировать с легаси лапшой но отдающей туже страницу за 50мс.

Да ладно, не всё так уж плохо

странный наброс) вся объектная лапша нынче даёт примерно +0.000000001 оверхеда) у тебя устаревшая инфа для наездов на пхп) версии ентак на 4

Сидел тут думал думал короче. И пришел к выводу что нормально спроектированное приложение по всем канонам ооп в пхп просто обречено на провал. И все из-за жизненного цикла приложухи. Короче с каждым запросом как птица феникс возрождается и потом снова умирает. Мало того что язык с большушим таким оверхедом сам по себе, так еще и это вот все жрет ресурс как не в себя Взять к примеру Syllius да. Все там вроде очень красиво выглядит, Но сцук когда открываешь магазины, на нем реализованные и видишь отдачу хтмлки в 2-3 секунды... это очень удручает. Оно в принципе не способно конкурировать с легаси лапшой но отдающей туже страницу за 50мс.

1. есть php-pm и подобные вещи. Потому ты можешь дать птице фенексу обработать 200-300 запросов перед смертью. 2. sylius мега жирный не потому что "ооп" а потому что универсальность. Ну и опять же - кэш все исправит)

ох нихерасебе у него список зависимостей)

запретить отдачу хтмл-ок пыхой, делов то)

странный наброс) вся объектная лапша нынче даёт примерно +0.000000001 оверхеда) у тебя устаревшая инфа для наездов на пхп) версии ентак на 4

не +0.00000000001 Достаточно открыть бенчмарки фреймворков и посмотреть что да как. В краце: чем говнее - тем лучше производительность

не +0.00000000001 Достаточно открыть бенчмарки фреймворков и посмотреть что да как. В краце: чем говнее - тем лучше производительность

причём тут бенчмарки фреймворков?

при том

л - логика

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

сам подумай пожалуйста

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