Концепция, как пишет Александр, была. При нормально проработанной не такой уж и трэш

Трэш в том, что это огромный кусок текст

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

И там написано как делать, вместо того, чтобы писать что делатт

Но может я просто плохие примеры видел

Скорее всего. Нормальный концепт (в моем представлении) содержит:
1. как\для чего\кому \когда..... делать\не делать. Т.е. мысли "как делать" часто могут помочь не делать за зря и понять реальность
2. что делать, для гибкой разработки - карта историй, истории: пусть не глубоко проработанные, местами даже большие эпики.

и вот как раз на основе этого брать на спринт в глубокую проработку кусочки

И зачем делать

Угу :(

Добрый вечер. Есть какой-то материал, как в веб-магазинах *нормально* делаются товары с фильтрами и категориями? Условно в категории "элетроника" есть подкатегория "мониторы", где группа фильтров, один из фильтров "диагональ": 18", 27", ..., etc. Как это обычно представляют в БД и какой движок поиска обычно применяют?
Читал про Apache Solr и ElasticSearch, как я понимаю, что всё сводится к использованию более заточенного на поиск решения вместо БД ценой необходимости постоянного обновления индекса (например, после обновления товара в бд нужно дообновить и индекс ElasticSearch), так?

Мы делали похожее в поиске недвижимости

Я понимаю, что это не вебмагазино-специфичное. Категории и фильтры это избитая тема, но я, увы, не видел вживую нормальных реализаций. Видел ужасы вплоть до "вкорячим фильтры прямо в SQL запрос интерполяцией строк", и ничего, такое в проде жило видимо. Написал сюда в надежде, что тут люди в теме и шарят поболе, как сделать такое нормально, а точнее на чём и как построить архитектуру этого решения в плане логической модели БД и выбора средств реализации на практике. Пока из подтверждённого в стеке только PostgreSQL на самом деле.

Как я понимаю, у вас фильтров может быть много, но категория как мне кажется "Недвижимость", или какие категории вы выделяли?

Нет, там куча категорий

Офисы, жилые помещения , гаради

Ну у нас ТЗ не одним куском разрабатывалось. Это такая прям коллаборативная работа.

Так. Строят индекс в условном elasticsearch с обновлением документов в индексе при обновлении данных в бд.

Свойства товаров это вроде EAV

Но это совсем плохое решение обычно (
Очень медленное

Так его в эластик уже загоняют и им ищут

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