К вопросу зачем товару вообще агрегат.

Отлавливать состояния, когда товар удален допустим из меню и помечать его.
Если у товара изменялась цена - то переходить в состояние "неподтвержденное" и ждать, пока пользователь согласится с новой ценой.
С примером, когда внутри товара есть какие-то дополнения, то контроллировать чтобы их не было больше/меньше заданного количества

с кем делать?

Как удаление товара из менб связано с изменением цены товара? Как они связаны с дополнениями?
Почему они вдруг были запихнуты в один объект в одну транзакцию?

Прежде всего для соблюдения правил.
Один из примеров - максимальное количество идентификаторов для одного товара

как это связано с изменением цены и удалением?

зачем все их пропихивать в одно место в одну транзакцию в один аггрешат? Какой тип кожижена будет в таком случае?

Хорошо, а куда это девать?

Опять выносить в сервисы? Тогда будет анемичная модель

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

"корзина" которая меняет статус - это больно)

Привет всем. А насоветуйте, какое хранилище сейчас самое норм для реализации условной витрины "яндекс-маркета". То есть большое количество данных в MySQL в N табличках, надо их фильтровать. И оно уже не тащит. В бюджет поставить N серваков уже не вписывается. Извращённых комбинаций фильтров может быть слишком много чтобы приготовить N индексов заранее. Плюс есть правила вроде "в категории товаров X первыми должны идти 10 штук, помеченные как оснвные".

Как я делал подобное раньше: строил индексы в Sphinx/SOLR/Elastic денормализованные из всего подряд + ещё витруальные поля для вычисляемых флагов, обновлял realtime при изменении записей в основной системе.

Минусы: гемор с RT обновлениями, думать надо над денормализацией, приходится бороться с желанием поисковых движков везде вкарячить веса и нечёткий поиск по дефолту. В остальном вроде работало норм на приличных объёмах с небольшими нюансами.

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

Насколько знаю условного лидера нет) Кто то использует sphinx и аксенова нанимает, что-то solr/эластик берет и накручивает все сверху

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

очень, но такова селяви, что встречается

Это как раз без разницы. Ну добавляется чуть очередей...

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

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

а так если б было все в базе, я б с эластиком извращался

вроде как ничего лучше эластика и ко не придумали для этих целей =)

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

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

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

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